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ABSTRACT 


CDRJL:  B008 
29  January  1994 


In  order  to  increase  awareness,  explore  current  research  into  software  architectures  as  a  means 
of  implementing  software  reuse,  and  examine  current  practices  and  issues  involving 
architectures,  the  Central  Archive  for  Reusable  Defense  Software  (CARDS)  Program 
sponsored  a  Software  Architecture  Seminar  and  Workshop  at  West  Virginia  University’s 
Concurrent  Engineering  Research  Center  (CERC)  facility  in  Morgantown,  West  Virginia  on 
November  16  and  17, 1993.  The  goals  of  the  Seminar  and  Workshop  were  to  understand  the 
various  meanings  of  software  architecture,  current  research  in  the  held  of  architecture,  and 
current  efforts  in  applying  software  architecture.  This  document  provides  highlights  of  the 
Seminar  and  Workshop. 

This  document  contains  an  overview  of  the  proceedings  of  the  Architecture  Seminar  on 
Tuesday,  November  16  and  the  Architecture  Workshop  on  Wednesday,  November  17.  This 
includes  issues  discussed,  questions  and  answers,  working  group  discussions,  and  references. 
This  document  also  contains  presentation  slides  from  the  Seminar,  the  Seminar  panel 
discussion,  and  the  Workshop. 


PREFACE 


CDRL:  B0O8 
29  January  1994 


Just  as  the  CARDS  Software  Architecture  Seminar  and  Workshop  could  not  have  been  a 
success  without  the  efforts  of  many  individuals,  this  document  also  is  based  on  the  efforts  of 
many  contributing  authors.  Thanks  to  primary  authors  Kurt  Wallnau,  Paul  Kogut,  Charlie 
Snyder,  and  Kerri  Haines,  of  Unisys  Corporation,  for  their  efforts,  work,  and  research,  and  all 
CARDS  Program  members  who  contributed  to  the  Seminar  and  Workshop. 

The  CARDS  Program  also  thanks  all  participants,  who  were  able  to  make  the  Seminar  and 
Workshop  enjoyable  and  enlightening. 

Comments  on  this  document  are  welcomed  and  encouraged. 
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1  Introduction 

In  an  effort  to  improve  software  quality  and  coat  effectiveness,  the  Department  of  Defense 
(DoD)  is  actively  endorsing  software  reuse,  the  process  of  implementing  new  systems  by 
using  existing  software  products  and  information.  As  noted  in  die  DoD  Software  Reuse 
Initiative  Vision  and  Strategy,  DoD  aims; 

[t]o  drive  the  DoD  software  community  from  its  current  “re-invent  the 
software "  cycle  to  a  process-driven,  domain-specific,  architecture-centric, 
library-assisted  way  of  constructing  software. 

A  key  element  of  the  Vision  and  Strategy,  architecture-centric  reuse  involves  defining  reuse- 
oriented  flexible  architectures  far  DoD  domains  which  are  well  supported  by  industry  and  the 
R&D  community,  then  spurring  investment  in  creation  of  generic  software  components  and 
tooling  which  facilitates  development  of  systems  complying  with  approved  architectures.  The 
creation  of  generic  components  must  be  independent  of  development  of  fieldable  production 
systems.  One  of  the  principal  challenges  of  reuse  is  to  develop  processes  and  standards  that 
can  facilitate  development  of  a  convention  that  enables  effective  sharing  of  components. 

In  order  to  increase  awareness,  explore  current  research  into  software  architectures  as  a  means 
of  implementing  software  reuse,  and  examine  current  practices  and  issues  involving 
architectures,  the  Central  Archive  for  Reusable  Defense  Software  (CARDS)  Program 
sponsored  a  Software  Architecture  Seminar  and  Workshop  at  West  Virginia  University’s 
Concurrent  Engineering  Research  Center  (CERC)  facility  in  Morgantown,  West  Virginia  on 
November  16  and  17,  1993.  The  goals  of  the  Seminar  and  Workshop  were  to  understand  the 
various  meanings  of  software  architecture,  current  research  in  the  field  of  architecture,  and 
current  efforts  in  applying  software  architecture.  This  document  provides  highlights  of  the 
Seminar  and  Workshop. 

1.1  The  CARDS  Program 

The  Central  Archive  for  Reusable  Defense  Software  (CARDS)  Program  is  a  concerted  DoD 
effort  to  transition  advances  in  the  techniques  and  technologies  of  domain-specific  software 
reuse  into  mainstream  DoD  software  procurements.  This  technology  transition  effort 
combines  a  concrete  demonstration  project  to  illustrate  the  potential  of  domain-specific  reuse 
—  in  this  case  for  the  domain  of  Command  Centers  --  with  a  broad-scale  attack  on  the  cultural 
and  contractual  inhibitors  to  software  reuse.  The  CARDS  Program  goals  are  to: 

•  Produce,  document,  and  propagate  techniques  to  enable  domain-specific 
reuse  throughout  the  DoD 

•  Develop  and  operate  a  domain-specific  library  system  and  necessary  tools 

•  Develop  a  Franchise  Plan  which  provides  a  blueprint  for  institutionalizing 
domain-specific,  library-centered  reuse  throughout  the  DoD 

•  Implement  the  Franchise  Plan  with  users  and  provide  a  tailored  set  of 
services  to  support  reuse 
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12  Document  Organization 

This  document  is  organized  into  five  chapters  and  two  appendices. 

Chapter  One,  Introduction ,  provides  a  general  introduction  to  the  document 

Chapter  Two,  Software  Architecture  Seminar ,  gives  a  summary  of  the  Seminar  and  Seminar 
Panel  Discussion,  along  with  highlights  of  issues  discussed. 

Chapter  Three,  Software  Architecture  Workshop ,  provides  a  summary  of  the  Workshop  and 
issues  surrounding  the  Workshop  presentations. 

Chapter  Four,  Architecture  S'-ninar  and  Workshop  Summary ,  contains  a  summary  of  the  two 
day  event  based  upon  evaluanon  forms  which  were  distributed  to  all  participants. 

Chapter  Five,  Architecture  Seminar  and  Workshop  Presentation  Slides,  contains  over  500 
presentation  slides  from  the  Seminar.  Panel  Discussion,  anu  Workshop. 

Appendix  A  is  a  list  of  all  participants,  along  with  contact  information. 

Appendix  B  is  a  bibliography  of  sources  used  for  development  of  the  Seminar,  and  suggested 
sources  for  additional  information. 
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2  Software  Architecture  Seminar 

This  Chapter  outlines  the  proceedings  and  key  points  of  the  CARDS  Software  Architecture 
Seminar  conducted  on  November  16,  1993.  The  Seminar  consisted  of  formal  presentations 
followed  by  a  panel  discussion.  Accompanying  presentation  slides  and  speaker  notes  for  the 
Seminar  and  the  Panel  Discussion  are  located  in  Chapter  Five;  page  numbers  for  the  slides  are 
noted  in  text 

2.1  Seminar  Proceedings  Summary 

The  Architecture  Seminar  was  divided  into  five  sessions: 

•  Session  I  Why  Architectures? 

•  Session  II  Senses  of  Architecture:  Building  the  Category 

•  Session  HI  Software  Architecture  and  Reuse 

•  Session  IV  Architecture-Based  Reuse  Tools 

•  Session  V  CARDS  Approach  to  Reuse  and  Software  Architecture 

Session  I  (pages  35-58)  of  the  Seminar  focused  on  why  architectures  are  needed,  why 
architectures  are  becoming  more  evident  and  definitions  of  architecture.  A  major  topic  of 
discussion  in  Session  I  was  the  various  definitions  of  architecture  and  style;  the  notion  of 
architecture  often  depends  on  the  perspective  of  the  individual  or  organization. 

Session  n  (pages  59-140)  built  upon  die  definition  of  architecture  discussion  in  Session  I, 
drawing  parallels  to  perspectives  in  manufacturing  and  engineering.  Session  n  then  contained 
overviews  of  software  architecture  from  a  scientific  foundation,  engineering  application,  and 
considerations  in  practice. 

Session  HI  (pages  141-216)  examined  architecture  from  a  reuse  standpoint,  concentrating  on 
architecture  “defined,”  the  science  of  architecture,  trends  in  architecture  for  reuse,  and 
architecture-based  reuse  systems. 

Session  IV  (pages  217-274)  involved  a  examination  of  specific  architecture-based  reuse  tools. 

Session  V  (pages  275-321)  presented  the  CARDS  approach  to  Domain  Engineering  activities 
as  related  to  software  architectures  and  reuse  from  scientific,  engineering,  and  transition-to- 
practice  views. 

2.2  Seminar  Proceedings  Issues 

Throughout  the  Seminar,  many  participants  raised  issues  on  Seminar  topics  which  generated 
discussion.  This  section  highlights  some  of  these  issues  and  includes  some  of  the  questions 
raised  by  participants. 
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2.2.1  Style 

A  gignifir-nnf  topic  of  discussion  during  the  Seminar  was  architectural  style. 

The  question  was  raised:  can  we  name  styles  of  architecture  (pages  87-98,  143-160)?  It  was 
that  there  are  certain  specializations  and  rules,  but  there  are  limited  capabilities  on 
how  to  apply  these  specializations  and  rules.  There  is  a  significant  challenge  in  that  there  is  no 
formal  representation  or  formal  basis  to  build  systems.  But,  there  are  tools  for  use  in  the  “real” 
world. 

It  seems  we  are  still  in  a  pre-paradigm  stage  regarding  style.  There  may  be  a  style  emerging 
for  real  timp.  systems  but  it  is  very  immature;  since  it  is  difficult  to  get  a  good  definition  for 
architecture,  it  is  difficult  to  get  a  clear  style.  There  is  still  confusion  on  defining  architectures, 
and  what  style  actually  is. 

One  participant’s  previous  understanding  of  style,  was  design  patterns  plus  organizational 
structures  plus  the  ensemble  (system  specific  features),  but  now  the  notion  of  style  implies 
globality.  Another  participant  offered  that  a  computational  model  (how  the  components 
communicate)  is  the  style,  and  that  the  computational  model  is  the  prime  distinguishing 
feature  between  architectural  styles.  Also,  there  are  well  known  computational  models. 

With  regard  to  the  characteristics  of  an  architecture,  one  participant  stated  that  he’d  like  to 
apply  a  test  to  architecture  and  style:  if  one  has  an  architecture  to  preserve  behavioral 
attributes  (such  as  security),  where  is  this  information  captured?  It  was  observed  that  some 
systems  may  have  wonderful  qualities  but  bad  style.  These  questions  must  be  considered: 
What  elements  of  design  have  to  be  represented?  Where  does  it  stop?  It  was  offered  that 
architectural  models  should  focus  on  an  understanding  of  style  and  coherence. 

Another  participant  noted  that  there  is  a  larger  issue  still;  everything  has  an  architecture  but 
architectures  are  viewed  subjectively.  However,  there  is  objectivity  regarding  style: 
understandability. 

The  point  was  also  made  that  with  regard  to  emphasis  on  style,  the  emphasis  must  be  on  all 
elements.  It  was  also  pointed  out  that  one  should  ensure  that  style  captures  operational 
principles;  software  designs  often  end  up  with  style  cluttering  it  up  or  getting  in  the  way. 
Another  observation  was  that  functionality  is  the  key;  style  alone  is  not  enough. 


2.2.2  Architectures  Defined 

With  regard  to  the  definition  of  architectures  (pages  45-50,  85-98,  145-152),  one  participant 
noted  that  based  on  experience,  architectures  should  be  at  a  higher  level  of  reuse.  There  needs 
to  be  a  move  away  from  expressing  this  as,  for  example,  a  compiler,  so  that  architectures  can 
move  closer  to  DoD  application  areas  and  can  be  used  as  examples  for  better  understanding 
by  management  level  personnel.  It  was  also  noted  that  somewhere  there  should  be  data  and 
process  views  for  mature  design  areas,  such  as  combat  weapons  systems.  Another  participant 
noted  the  importance  of  domain  independence;  we  should  think  of  things  that  will  work  in 
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different  systems. 

In  a  discussion  of  work  done  by  Don  Batary  regarding  design  methods  and  architectural  style 
(pages  125-12 6),  several  participants  made  comments.  Some  felt  that  Batory’s  work  is  similar 
to  others,  but  differs  only  in  perspective.  It  is  notable  that  Batory  used  a  recursive  way  of 
putting  modules  together,  with  the  only  difference  being  data  types.  Another  participant  noted 
that  Batory’s  method  “feels”  different,  while  another  noted  that  Batory’s  work  was  somewhat 
domain  dependent 

The  point  was  made  that  Batory’s  work  lodes  similar  to  other  processes,  but  that  he  arrived  at 
his  results  in  a  different  manner.  Batory  didn’t  start  with  idioms;  he  performed  a  domain 
analysis  and  abstracted  idioms.  Through  domain  analysis  and  domain  modeling,  new  idioms 
can  be  found  and  the  form  of  architecture  can  be  the  same. 

It  was  also  questioned  if  language  should  be  used  to  drive  the  system.  A  response  was  that 
form  comes  from  the  design  method,  and  that  language  should  be  at  the  level  of  components 
and  connectors.  One  participant  felt  that  there  was  no  difference,  while  another  felt  that  the 
difference  is  only  in  perspective. 

It  is  possible  the  difference  between  architecture  and  software/computer  systems  is  that 
computer  systems  deal  with  codifying  a  wide  range  of  business  processes.  When  building  a 
system  to  support  these  processes,  there  is  a  clash  between  pre-defined  components  and  the 
process  which  you’re  trying  to  support  This  calls  for  a  close  look  at  requirements. 

In  Session  m,  seven  characteristics  of  software  architecture  were  discussed  (pages  147-150). 
One  participant  noted  that  it  is  easy  to  see  the  part  in  the  whole,  but  how  can  one  see  the 
whole?  Does  seeing  the  part  in  the  whole  actually  change  the  part?  One  reply  was  that  if  one 
can  see  the  part,  such  as  a  subsystem,  one  doesn’t  necessarily  need  to  see  the  whole,  but  can 
gain  an  understanding  of  the  whole  system. 

2.23  CARDS  Approach 

In  the  discussion  concerning  the  CARDS  approach  to  reuse  and  architectures  (pages  281-285, 
301-308),  one  participant  observed  that  Prieto-Diaz’s  idea  of  a  faceted  classification  scheme 
usually  results  in  5  or  6  facets,  while  the  CARDS  approach  involves  more.  CARDS  chooses  to 
show  more  relationships,  and,  having  a  model-based  library,  concentrate  on  representing  a 
domain-specific  model.  Also,  one  participant  noted  that  a  knowledge  based  classification 
scheme  can  also  involve  a  high  cost  to  implement  and  maintain. 


2.3  Seminar  Panel  Discussion  Summary 

The  panel  discussion  included  presentations  from  four  participants,  followed  by  a  question 
and  answer  discussion.  The  four  panel  members  were: 

•  Mr.  T.  F.  “Skip”  Saunders,  Mitre  Corporation 

•  Mr.  Hans  Polzer,  Unisys  Corporation 
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•  Mr.  Stan  Levine,  US  Army  Communications  Electronics  Command 
(CECOM) 

•  Capt  Frederick  Swartz,  Draining  System  Program  Office,  ASC/YTE 

The  panel  discussion  consisted  of  presentations  from  each  panel  member.  Mr.  Saunders 
presented  views  on  architecture  and  reuse  in  terms  of  three  points:  goals,  views,  and  trends 
(pages  324-371).  Mr.  Polzer's  presentation  (pages  372-383)  concentrated  on  the  economic 
factors  surrounding  architectures.  Mr.  Levine  offered  some  case  history  examples  and  l^c^ns 
learned  on  projects  involving  architectures  (pages  384-423).  Captain  Swartz  discussed  the 
role  of  architectures  or  structural  models  in  proposals  (pages  424-435). 

2.4  Seminar  Panel  Discussion  Issues 

2.4.1  Open  Systems 

One  participant  questioned  the  panel  regarding  opeh  systems.  The  participant’s  customer  had 
requested  that  architectures  be  re-defined  to  open  systems,  presenting  difficulties  in 
conflicting  standards.  The  question  was  raised:  are  architectures  and  open  systems  the  same? 

With  regard  to  open  systems  and  architecture,  issues  such  as  compatibility  and  interoperation 
are  often  difficult;  products  are  often  built  to  different  standards.  However,  these  issues  need 
to  be  considered  from  an  architectural  standpoint  so  that  components  will  connect  in  a 
disciplined  manner.  This  is  starting  to  surface  in  the  commercial  sector.  However,  a  problem 
in  the  Government  arena  is  that  the  Government  can  not  specify  one  single  system;  this  could 
lead  into  contracting/legal  difficulties.  Therefore,  the  Government  states  the  properties  of  a 
desired  system,  then  leaves  it  up  to  the  contractor  to  decide  how  to  meet  the  requirements.  The 
Government  then  evaluates  the  contractor’s  approach. 

The  solution  also  depends  on  one’s  definition  of  open  system.  A  system  doesn’t  necessarily 
have  to  follow  a  Government  sanctioned  standard.  One  approach  is  to  follow  an  economic 
approach:  what/how  much  financial  resources  are  available  and  “is  it  for  me”  in  relation  to 
risk?  Often  open  systems  aren’t  really  open;  there  are  so  many  alternatives.  “Open” 
sometimes  means  avoiding  a  large  economic  lock-in  while  still  accomplishing  what  was 
wanted.  Also,  from  the  Government  point  of  view,  there  may  be  times  when  a  Government 
agency/customer  can’t  afford  an  open  system.  It  may  be  best  to  let  the  contractor  decide. 

2.4.2  Structural  Modeling  and  Proposals 

Several  participants  were  interested  in  specifying  certain  architectures  (referred  to  in  this 
context  as  structural  models)  in  Statements  of  Work  (SOWs)  and  Requests  For  Proposal 
(RFPs)  (pages  424-435). 

At  times,  the  Government  may  not  want  to  limit  the  contractor  by  specifying  a  certain 
architecture;  other  times,  the  Government  may  be  limited  by  policy  assuring  that  bids  are 
competitive.  Also,  architectures/structural  models  are  still  relatively  new  and  not  well  defined. 
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Architectures/structural  models  can  be  in  SOWs  as  long  as  a  specific  product  is  not  specified. 
However,  there  need  to  be  trained  people  who  know  the  structural  model  and  there  must  be  no 
flaw  in  the  structural  model.  Also,  if  the  arehitecture/structuml  model  is  not  specified,  then  no 
one  may  bid  it 

In  order  to  evaluate  proposals,  evaluatable  criteria  must  be  in  the  SOW/RFP.  The  criteria  that 
are  pushing  the  use  of  a  certain  architecture  must  be  known.  A  track  record  that  the 
architecture  works  will  help.  If  there  is  no  track  record,  one  option  is  to  let  the  contractor  offer 
an  architecture  or  structural  model,  remembering  that  the  burden  will  still  remain  on  the 
issuer/Govemment  It  is  important  to  know  what  attributes  are  desired. 

2.43  The  New  Concept  of  Architecture 

There  was  some  debate  as  to  whether  architectures  are  a  new  concept,  or  have  been  used  for 
some  time.  Often  architectures  are  developed  unplanned.  Whale  the  development  community 
seems  to  have  been  using  architectures  for  a  long  time,  current  ftmphncic  ^  on  theh 
formalization.  Pieces  of  a  system  are  better  defined  when  this  formalism  is  in  place.  It  also 
appears  that  vendors  are  now  able  to  dictate  architectures  used  in  their  products. 
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3  Software  Architecture  Workshop 

This  Chapter  outlines  the  proceedings  and  key  points  of  the  CARDS  Software  Architecture 
Workshop  conducted  on  November  17,  1993.  The  Architecture  Workshop  began  with 
presentations  from  leading  Government  and  industry  specialists  on  current  efforts  and 
research  in  software  architecture.  The  participants  then  split  into  six  working  groups  to 
continue  Hisnusainn  and  examine  issues  in  particular  fields  of  interest  Accompanying 
presentation  slides  and  speaker  notes  for  the  Workshop  are  located  in  Chapter  Five  of  this 
document;  page  numbers  for  the  slides  are  noted  in  text 


3.1  Workshop  Presentation  Summary 

Fourteen  individuals  representing  Government  and  industry  gave  short  presentations  on  their 
current  work  in  architectures.  These  diverse  presentations  offered  an  enlightening  view  into 
the  latest  views  and  practices  regarding  software  architectures,  their  respective  definitions, 
and  role  in  application  engineering.  Workshop  presentations  were  given  by: 

•  Mr.  Will  Tracz,  IBM  FSD  (pages  442-457) 

•  Mr.  Mark  Gerhard t,  ESL,  Inc.  (pages  458-471) 

•  Ms.  Deborah  Gary,  DISA  (pages  472-479) 

•  Mr.  Jim  Baldo,  Unisys  (pages  480-489) 

•  Mr.  Charles  Plinta,  ACCEL  (pages  490-505) 

.  Capt  Paul  Valdez,  USAF  ESQENS  (pages  506-513) 

•  Mr.  Ulf  Olsson,  CelsiusTech  Systems  (pages  514-527) 

•  Mr.  Jim  Bonine,  Design  Metrics  Technology  (pages  528-533) 

•  Mr.  Steve  Roodbeen,  NUWC  (pages  534-543) 

•  Major  Grant  Wickman,  CECOM  (pages  544-551) 

•  Capt  Kelly  Spicer,  USAF  SWSC/SMX  (pages  552-561) 

•  Mr.  Stellan  Kamebro,  Defence  Materiel  Administration  (pages  562-574) 


3.2  Workshop  Presentation  Issues 

Because  of  the  diverse  composition  of  the  Workshop  speakers,  many  issues  surrounding 
software  architectures  and  reuse  were  examined.  The  following  is  an  overview  of  some  of 
those  issues,  along  with  key  points  of  discussion. 

3.2.1  The  Role  of  Software  Architectures 

People  often  feel  that  they’re  communicating  requirements  effectively,  but  may  instead  have 
different  views.  An  architecture  can  serve  as  a  common  point  of  reference.  Blueprints, 
schematics,  and  the  like  are  all  ways  that  people  communicate  in  their  elements. 
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Architecture  is  the  software  communication  vehicle.  Fran  an  architecture  point  of  view, 
systems  are  treated  as  components. 

How  can  architectures  be  used  in  maintenance  and  sustained  engineering  activities?  Mission 
needs  shift  with  time;  as  time  goes  by,  things  change.  It  is  valuable  to  have  a  process  for 
transition  from  one  architecture  to  another  as  technology  changes. 

In  using  domain  specific  software  architectures,  meeting  requirements  and  creating  particular 
applications  in  a  solution  space  may  create  tension.  A  solution  is  to  draw  the  line  between  the 
problem  space  and  the  solution  space:  create  a  domain  model,  pick  out  constraints,  then  create 
specific  applications. 

Currently,  components  aren't  always  compatible.  Fatal  component  combinations  must  be 
recognized.  The  mare  layers  that  are  added  to  a  software  architecture,  the  less  interaction 
there  may  be  between  components.  In  some  cases,  it  may  be  best  to  extract  high  level 
elements  and  start  from  scratch,  rather  than  try  to  ‘extract  low  level  components  to  build  a 
system. 

3.2.2  Investment  Considerations 

The  more  detailed  standards  are,  the  more  difficult  it  may  be  to  communicate  to  another 
platform.  One  solution  is  to  publish  a  set  of  “building  codes”  with  a  broad  scope  that  will 
allow  for  architected  systems. 

There  must  be  investment  into  a  software  architecture  before  it  can  be  used.  Tnipai  cost  of 
software  architecture  development  may  be  prohibitive.  Also,  some  projects  may  be  closing 
down  due  to  budget  constraints.  The  knowledge  from  these  projects  needs  to  be  captured 
rather  than  lost  This  approach  involves  capturing  a  design  hierarchy,  documentation, 
development  history,  and  design  decisions. 

Some  felt  the  use  of  architectures  may  not  apply  to  all  kinds  of  systems,  such  as  real  time 
embedded  systems  at  this  point  in  time. 

Experiences  and  experiments  in  developing  architectures  need  to  be  documented,  even  from 
fatal  architectures. 

3.2.3  Architectures  Defined 

A  good  architecture  is  stable  with  a  cover  of  customizations,  while  a  poor  architecture  is  the 
reverse  with  props  to  make  it  stable.  When  customizations  get  too  bulky,  they  outweigh  the 
base  and  make  the  system  unstable. 

Architectures  are  frameworks,  but  are  not  necessarily  a  solution;  architectures  are  a  layered 
subset  of  the  solution. 

Every  design  problem  has  an  objective  logical  architecture.  A  logical  architecture  is  an 
architecture  in  purely  mathematical  form. 
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33  Workshop  Working  Group  Summaries  and  Issues 

The  Workshop  participants  then  separated  into  working  groups  to  identify  common  problems 
involving  architecture  and  reuse  implementation,  and  to  develop  a  common  approach  to 
solutions  to  these  issues.  The  groups  were  organized  as  follows: 

•  Working  Group  1:  Evaluation  and  Measurement  of  Architectures 

•  Working  Group  2:  Software  Architecture  Technologies 

•  Working  Group  3:  Software  Architecture  and  Reuse 

•  Working  Group  4:  Software  Architecture  and  Standards 

•  Working  Group  S:  Software  Architecture  and  Strategic  (Product-line) 
Planning 

•  Working  Group  6:  System  Architecture  Technical  Committee  for  Reuse 
Library  Interoperability 

33.1  Working  Group  One:  Evaluation  and  Measurement  of 
Architectures 

Working  Group  One  concentrated  on  two  topic  questions: 

•  For  procurement  issues,  how  can  many  proposed  architectures  be 
evaluated? 

•  For  design  issues,  what  are  the  " architecture-level”  qualities  which  can 
and  should  be  measured? 

In  order  to  compare  one  architecture  against  another,  we  must  establish  a  common 
understanding  of  what  we  mean  when  we  refer  to  an  architecture.  Properties  we  are  looking 
far  in  an  architecture  should  be  specified.  We  should  provide  our  definition  of  an  architecture 
and  give  examples  of  how  we  represent  it 

1.  The  offeror  must  describe  the  architecture  in  10  pages  or  less  using  the 
following  guidelines: 

•  Describe  the  basic  elements  which  make  up  the  architecture. 

•  Define  the  rules  for  how  the  elements  interact  with  each  other. 

•  Describe  how  these  basic  elements  make  up  the  system  design. 

Evaluation  criteria: 

•  Is  the  design  based  on  the  architecture? 

•  Is  the  style  for  defining  and  representing  the  architecture  consistent? 

•  Are  the  functions  separate  from  the  interactions? 

•  Are  the  rules  for  combining  the  elements  consistent? 
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2.  Evaluate  the  offerer's  architecture  on  how  well  it  addresses  non-functional 
requirements  (e.g.,  interoperability,  ability  to  tolerate  change,  cheap  to  build, 
use  of  COTS).  The  offeror  must  explain  and/or  demonstrate  this  through  a 
prototype. 

Evaluation  criteria: 

•  Can  the  architecture  incorporate  new  functionality  based  on  new 
technology? 

•  How  much  COTS  software  is  used  and  at  what  level? 

•  The  ability  to  address  changes  in  requirements. 

•  How  the  system  interacts  with  other  systems  in  the  domain. 

•  Does  the  architecture  incorporate  open  system  standards? 

•  Can  stress  points  be  identified?  How  does  die  architecture  compensate? 

3.  Evaluate  the  offeror’s  architecture  with  respect  to  how  it  is  similar  or  different 
from  examples  provided  in  the  RFP. 

Evaluation  criteria: 

•  How  much  does  the  offeror  understand  about  the  domain? 

•  Did  the  offeror  find  innovative  improvements  to  the  architecture? 

3.3.2  Working  Group  Two:  Software  Architecture  Technologies 

Working  Group  Two  focused  on  the  following  topic  questions: 

•  What  are  the  current  and  emerging  technologies  for  software 
architecture? 

•  Where  is  the  “low  hanging  fruit’  (i.e.,  easily  attained  but  useful 
technology )? 

Views  about  software  architecture  technology  depend  upon  your  goal  and  perspective. 
Current  technologies  for  software  architecture  involve  the  following  issues: 

1.  Application  Composition 

•  Composition  formalisms 

•  Common  infrastructure 

2.  Techniques  for  Reusable  Components 

•  Multi-level 

•  Includes  context  for  use  definition  (operational,  testing,  development) 
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3.  Legacy  Systema/Software 

•  Extraction  of  architecture  and  components 

•  Reuse  in  existing  form 

Although  technologies  for  software  architectures  still  need  to  emerge,  there  currently  is 
vident  “low  hanging  fruit” 

1.  Object-Oriented  Technology 

•  Development 

•  Re-engineering 

2.  Formalisms  For  Composition 

•  Type  Expressions  (Batory) 

•  Architecture  Description  Languages 

3.  Interconnection  Techniques 

•  LIF,  MIF,  POLYLTIH 

•  UNAS 

•  Wrappers/mediators 

•  Standards:  CORB A,  OSI,  etc. 

4.  Parameterized  Programming 

5.  Consensus  Definition  of  Architecture 

6.  Inductive  Analysis  of  Current  Exemplars 

7.  VHDL  (Bailor) 

8.  Ontological  Structuring 

3.3.3  Working  Group  Three:  Software  Architecture  and  Reuse 

The  topic  questions  for  Working  Group  Three  were: 

•  What  does  it  mean  for  an  architecture  to  be  “reusable?" 

•  What  is  needed  for  product-line  architectures  to  sustain  a  commercial 
component  provider  industry? 

Working  Group  Three  presented  an  example  of  a  layered  architecture  for  discussion.  Layering 
helps  in  understanding  design.  However,  abstractions  may  be  violated  in  implementation,  and 
layering  may  be  incomplete.  Advantages  for  reuse  include  a  partitioning  strategy,  and  an 
abstraction  mechanism.  A  disadvantage  for  reuse  is  a  need  for  optimization. 
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With  regard  to  reusable  architectures  in  domains,  the  architecture  should  be  reusable  and 
should  also  support  the  reuse  of  components.  Do  these  conflict?  Is  there  an  issue  surrounding 
the  variability  of  components  versus  the  variability  of  die  architecture?  One  strategy  is  to 
utilize  generative  techniques  and  a  generic  architecture,  which  may  require  trade-offs.  It  is 
also  noteworthy  that  a  small  domain  is  more  vulnerable  to  external  architecture  constraints, 
and  that  a  large  domain  involves  a  large  number  of  resources. 

There  are  also  numerous  issues  for  consideration. 

Different  domains,  organizations,  and/or  audiences  may  have  different  architecture  languages, 
views,  representations,  and  levels  of  abstraction  (ravioli).  How  can  these  be  made  reusable? 

If  context  is  linked  to  architecture,  what  about  “domain-independent”  idioms?  Does  a 
class/inheritance  based  taxonomy  help  capture  this? 

Tension  between  architectural  “quality”  (from  fust  principles)  versus  fit  to  existing  systems. 

Are  there  “complete”  architectural  style  taxonomies,  e.g.,  OO  procedural,  pattern-directed 
inference,  list  processing? 

An  architecture  must  include  at  least  components,  connections,  constraints,  plus  context  and 
dynamic  aspects. 

Are  generic  architectures  applicable  for  every  domain?  Are  they  high  level  designs  with  “plug 
and  play”  variability  at  lower  levels? 

What  is  meant  by  reuse  in  architecture?  Reusable  architectures?  Component  reuse  in 
architectures?  What  is  the  difference  between  usability  and  reusability? 

Architectural  representations  as  assets:  Freely  accessible  versus  export  controlled?  Are  they 
attractive?  Are  they  from  fielded  systems? 

Facets/keywords  for  describing  architectures:  Are  they  agreed  to  (de  facto)?  Where  are  they 
documented  (standards)?  Can  they  be  retrofitted  to  existing  assets? 

Is  a  layered  architecture  descriptive  enough  to  describe  everything  needed  to  develop  a 
system?  For  reusability? 

Are  architectures  from  Domain  Analysis  results  integratible  with  existing  components?  Are 
architectures  from  existing  systems/components  limited  to  existing  capabilities? 

3.3.4  Working  Group  Four:  Software  Architecture  and  Standards 

Working  Group  Four  examined  two  topic  questions: 

•  What  is  the  relationship  between  architecture  and  open  systems? 
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•  What  are  the  areas  of  architecture  standardization,  e.g.,  “ building 
codes?" 

There  is  definitely  a  relationship  between  software  architecture  and  open  systems.  While  a 
“good”  architecture  is  cheap  and  modifiable,  a  “good”  architecture  also  exploits  open  systems 
for  the  lifetime  of  the  product  However,  an  open  system  should  not  dictate  the  architecture.  In 
this  context,  there  are  restrictive  standards;  this  applies  to  a  wide  range  and  to  certain  system 
attributes.  Also,  there  need  to  be  enabling  standards  which  deal  with  market  opportunity, 
especially  in  areas  such  as  component  suppliers  and  cost  effective  system  solutions. 

The  topic  of  standardization  ami  architecture  often  involves  architecture  and  multiple 
“building  codes.”  There  are  often  degrees  of  constraining  architecture,  and  regional  variation 
in  the  “codes.”  There  needs  to  be  standardization  at  various  layers  of  software  architecture. 
The  purpose  of  standardization  has  multiple  elements,  such  as: 

•  Portability 

•  Interoperability 

•  Product  Family 

•  Component  Supplier  Market 

•  Conformance 

•  Bureaucracy  Preservation 
Approaches  to  standardization  include: 

•  Proprietary,  Publicly  Known 

•  Negotiation 

•  Forum 

Areas  for  standardization  can  include: 

•  Interfaces  -  syntax  connections 

•  Data  Consistency  -  semantic  connections 

•  Usage  Consistency 

3.3.5  Working  Group  Five:  Software  Architecture  and  Strategic 
(Product-line)  Planning 

The  topic  questions  for  Working  Group  Five  were: 

•  Where  in  the  DoD  should  architectures  be  specified?  Maintained? 
Implemented?  What  are  the  prosicons  of  various  approaches? 

•  How  can  DoD  architectures,  if  specified,  be  used  prescriptively  in 
procuring  systems? 

Group  Five  noted  that  there  must  be  some  assumptions  made: 

•  Offerers  may  provide  an  architecture. 

•  It  is  important  that  the  Government  own  the  Domain  Model  (source  of 
evaluation  criteria). 
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The  following  issues  were  raised. 

How  do  we  convey  what  we  mean  by  architecture?  This  can  be  done  through  white  papers  and 
examples. 

What  questions  can  be  about  architecture  which  can  discriminate  alternative  proposals? 
There  is  reasonable  certainty  that  answers  to  this  question  will  be  different 

How  can  you  get  common  representations? 

How  is  it  possible  to  get  an  apples  to  apples  comparison  against  criteria?  Approaches  include: 

•  develop  evaluation  characteristics 

•  likely  to  be  non-functional 

•  scenarios  make  these  concrete  and  evaluatable 

3.3.6  Working  Group  Six:  System  Architecture  Technical 
Committee  for  Reuse  Library  Interoperability 

Working  Group  Six,  a  subgroup  of  the  Reuse  Library  Interoperability  Group  (RIG), 
concentrated  on  issues  surrounding  reuse  binary  interoperability.  A  topic  of  discussion  was: 

•  What  are  some  techniques  for  analyzing  and  comparing  architectures  (of 
reuse  libraries)  for  interoperability? 

The  discussion  was  difficult  because  of  vocabulary  problems,  but  a  suggestion  was  offered; 
there  should  be  at  least  the  possibility  of  a  domain  analysis  for  interoperability.  The  Group 
also  discussed  a  Technical  Reference  Model  (TRM)  for  interoperability.  This  can  be  divided 
into  three  elements: 

•  User  Services  (focus  on  the  end  user/the  driver) 

•  Support  Services  (common  for  interoperating  applications) 

•  Framework  Services  (common  for  all  interoperating  applications) 

1.  Using  end  user  services  maps  to  support  services  which  maps  to  the 
framework  in  order  to  interoperate. 

2.  Missing  user  services  indicate  missing  support  or  framework  services. 

3.  Adding  support  or  framework  services  implies  new  user  services. 

Projecting  the  TRM  through  the  architecture  shows  the  implications  of  the  architecture  style. 
Also,  this  will  work  for  designs  and  implementations,  providing  greater  detail. 
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4  Architecture  Seminar  and  Workshop  Summary 

Approximately  eighty  people  attended  the  Seminar  and  Workshop  on  November  16  and  17, 
1993.  Twenty-nine  participants  were  from  Government  or  DoD  organizations,  twenty-four 
represented  industry,  twelve  were  from  academia,  and  fifteen  were  from  CARDS  or  other 
organizations.  Key  points  from  the  Seminar  and  Workshop  include: 

1.  There  were  multiple,  valid  perspectives  regarding  architectures. 

•  Computer  Science  (idioms,  computational  models,  etc.) 

•  Design  (standards,  methods,  education,  etc.) 

•  Engineering  (prediction,  measurement,  non-functionals,  etc.) 

•  Systems  (high-level  designs  for  applications) 

2.  There  is  a  relationship  between  architecture  and  software  reuse. 

•  High-level  designs  accompanied  by  context  information 

•  Trends  toward  intersection  of  object-orientation  and  event  systems 

3.  There  is  significant  interest  in  the  subject  of  software  architectures. 

4.  While  the  Seminar  focused  on  technology,  there  are  equally  strong 
connections  to  economics. 

Participant  responses  and  results  from  evaluation  forms  are  in  the  following  sections. 

4.1  Evaluation  Form  Summary 

4.1.1  Overview 

As  Seminar  and  Workshop  participants  registered,  they  were  provided  with  evaluation  and 
feedback  forms  as  part  of  their  registration  packets.  Twenty-nine  of  the  participants 
responded,  and  the  following  results  are  based  on  those  responses. 

There  was  a  consensus  that  the  Seminar  and  Workshop  were  very  successful  and  beneficial, 
and  that  there  should  be  similar  events  in  the  future,  either  annually,  every  two  years,  or  every 
six  months.  Many  noted  that  there  should  be  more  time  allotted,  as  a  large  amount  of 
information  was  presented  in  a  relatively  short  me.  There  was  also  a  consensus  that  there 
should  be  smaller  working  groups  which  focus  on  particular  areas  of  interest. 

4.1.2  Detailed  Comments 

The  participants  suggested  that  particular  individuals  be  invited  to  future 
Seminars/Workshops .  That  list  includes  Bruce  Anderson  or  a  real  building  architect  and  a 
movement  training  specialist  (spatial  analogies),  Christopher  Alexander,  Gary  Whitted 
(IMASS  Program),  Rob  Sturtenant  (McDonnell  Douglas  and  CIT  °rogram),  select  individuals 
from  the  software  engineering  community,  architects  from  other  fields  (panel  session),  DISA, 
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CFA,  NRaD,  MICQM,  DSSA,  service  and  DoD  group  leaders  that  are  working  on  joint  and 
multi-service  common  architectures,  international  representatives  (Europe  and  Japan), 
Reuben  PrietoDiaz,  Shalom  Cohen,  Mary  Shaw,  and  John  Foreman. 

Several  suggestions  were  made  regarding  the  Workshop.  It  was  suggested  that  there  be  more 
working  groups  and  mare  time  for  discussion.  Also,  three  groups  in  one  room  was 
impractical.  It  would  be  better  to  have  smaller  working  groups;  if  they  must  be  large,  they 
should  focus  on  diverse  viewpoints  with  mechanisms  for  synthesizing  input  (e.g.,  future 
search  conference).  Some  noted  that  there  should  have  been  more  information  geared  to  the 
participant  who  has  limited  or  no  previous  knowledge  of  architectures.  The  next  Workshop 
should  attempt  to  produce,  as  a  group,  a  viewer  definition  of  software  architectures  and 
examples,  including  success  stories. 

Several  comments  were  also  made  with  respect  to  how  software  architectures  were  defined 
and  presented.  Comments  indicated  a  good  mix  of  CARDS  and  non-CARDS  experts.  One 
attendee  noted,  “I  think  the  audience  was  opened  t6o  broadly  too  early.  It  would  have  been 
better  to  have  an  initial  workshop  to  solidify  the  issues  and  CARDS  viewpoints  before  having 
a  workshop/forum  like  this  one.”  It  would  have  also  been  useful  to  have  the  CARDS 
Architecture  Task  Force  (AIT)  talk  delivered  earlier  to  provide  some  context  Also,  the 
tool/representation  survey  was  presented  with  virtually  no  context  and  was,  therefore, 
relatively  of  little  benefit 

It  was  suggested  that  there  be  more  specific  architectures  presented.  Following  this,  have 
participants  provide  constructive  criticism,  and  break  into  a  domain  working  group  and 
develop  architectures.  111611,  present  the  results  to  the  main  group.  There  could  have  been 
more  discussion  of  the  qualities  of  an  architecture  and  distinctions  between  design  and 
architectures.  Another  suggestion  was  to  have  more  examples  and  hands-on  interaction. 
Participants  want  information  and  examples  which  they  can  apply.  One  recommendation  was 
to  use  a  lecture  room  that  is  more  accommodating  for  this  type  of  event. 

Regarding  supporting  materials,  significant  papers  or  books  might  be  made  available,  either 
for  free  or  purchase.  Workshop  presentation  slides  should  be  provided  beforehand,  and 
handouts  should  also  be  provided  from  the  panelists  and  invited  guest  speakers.  A 
speaker/attendee  list  should  be  available,  as  well  as  more  information  provided  electronically. 
A  bibliography  with  list  of  references,  citations,  and  resources  should  also  be  distributed. 
Demonstrations  of  the  tools  should  be  included  (if  for  nothing  else,  to  interrupt  the  flow  of  the 
“talking  heads”). 

4.1.3  Evaluation  Form  Results 

Ninety-six  percent  of  responding  participants  acknowledged  that  they  would  be  able  to  apply 
knowledge  gained  from  the  Seminar  and  Workshop  on  the  job  and  three  percent  were  unsure. 
Sixty-eight  percent  said  they  had  some  previous  knowledge  of  software  architectures,  twenty- 
nine  percent  had  limited  knowledge,  and  four  percent  indicated  no  previous  knowledge  of 
software  architectures.  One  hundred  percent  of  responding  participants  said  that  their 
knowledge  of  software  architectures  was  enhanced  or  increased  in  some  way.  One  hundred 
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percent  also  desired  to  have  future  seminars.  Four  percent  preferred  to  have  diem  quarterly, 
twenty  four  percent  preferred  to  have  them  semi-annually,  sixty  eight  percent  preferred  to 
have  them  annually,  and  seven  percent  preferred  to  have  them  every  other  year. 

Additional  evaluation  form  results  are  summarized  below. 


Thble  1:  Time  Given  for  Each  Session 


%  Too  Specific  I  %  Too  General  I  %  Adequate 


Thble  2:  The  Material  Covered 
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Thble  3:  Contents  of  Concepts 


Refreshments 


Facilities 


Visual  Aids 


Lunch 


Handouts 


Examples 


%Poor 


8 


8 


%Fair 


12 


15 


20 


19 


’  27 


Table  4:  Supporting  Services 


%  Good 

%  Excellent 

58 

23 

50 

26 

63 

15 

50 

8 

43 

50 

46 

15 

%  Poor 

%  Fair 

%  Good 

%  Excellent 

N/A 

Knowledge 

— 

8 

48 

44 

— 

Responses 

— 

5 

15 

24 

— 

Selection 

— 

9 

57 

35 

— 

Table  5:  Panel  Discussion 


Page  19 


STARS- VC-B008/301AX) 


29  January  1994 


5  Architecture  Seminar  and  Workshop  Presentation  Slides 

This  Chapter  contains  presentation  slides  from  the  Seminar,  the  Seminar  panel  discussion,  and 
the  Workshop.  The  slides  are  divided  into  three  sections,  prefaced  by  introductory  slides. 

Software  Architecture  Seminar  slides  (pages  21-321)  are  from  the  five  Seminar  sessions: 

•  Session  I  Why  Architectures  (pages  3S-S8) 

•  Session  n  Senses  of  Architecture:  Building  the  Category  (pages  39-140) 

•  Session  m  Software  Architecture  and  Reuse  (pages  141-216) 

•  Session  IV  Architecture-Based  Reuse  Tools  (pages  217-274) 

•  Session  V  CARDS  Approach  to  Reuse  and  Software  Architecture  (pages 
275-321) 

Slides  from  the  Seminar  Panel  Discussion  (pages  322-435)  were  used  by  die  four  panel 
members: 

•  Mr.  T.F.  “Skip”  Saunders,  Mitre  Corporation  (pages  324-371) 

•  Mr.  Hans  Polzer,  Unisys  Corporation  (pages  372-383) 

•  Mr.  Stan  Levine,  US  Army  CECOM  (pages  384-423) 

•  Capt  Frederick  Swartz,  USAF  ASC/YTE  (pages  424-435) 

Software  Architecture  Workshop  slides  (pages  436-574)  are  from  Workshop  presentations 
given  by: 

•  Mr.  Will  Tracz,  IBM  FSD  (pages  442-457) 

•  Mr.  Mark  Gerhardt,  ESL,  Inc.  (pages  458-471) 

•  Ms.  Deborah  Gary,  DISA  (pages  472-479) 

•  Mr.  Jim  Baldo,  Unisys  (pages  480-489) 

•  Mr.  Charles  Plinta,  ACCEL  (pages  490-505) 

•  Capt  Paul  Valdez,  USAF  ESC/ENS  (pages  506-513) 

•  Mr.  Ulf  Olsson,  CelsiusTech  Systems  (pages  514-527) 

•  Mr.  Jim  Bonine,  Design  Metrics  Technology  (pages  528-533) 

•  Mr.  Steve  Roodbeen,  NUWC  (pages  534-543) 

•  Major  Grant  Wickman,  CECOM  (pages  544-551) 

.  Capt  Kelly  Spicer,  USAF  SWSC/SMX  (pages  552-561) 

•  Mr.  Stellan  Kamebro,  Defence  Materiel  Administration  (pages  562-574) 

The  slides  from  the  Panel  Discussion  and  the  Workshop  were  optically  scanned  and  imported 
into  this  document.  Page  numbers  are  at  the  bottom  right  comer. 
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Welcome  to  CERC 


CARDS  would  like  to  thank  tha  Concurrent  Engineering  Research  Center 
(CERC)  for  donating  the  use  of  their  facilities  to  host  this  seminar. 

CERC  was  established  in  1988  by  the  DoO’s  Advanced  Research  Projects 
Agency  (ARPA)  in  response  to  a  national  need  to  improve  the  product 
development  capabilities  of  the  U.S.  defense-industrial  base.  As  the 
centerpiece  of  the  (D)ARPA  Initiative  In  Concurrent  Engineering  (DICE), 
CERC's  mission  is  to  design,  develop,  and  promote  concurrent  engineering 
technologies. 

CERC  has  recently  expanded  the  application  of  its  technology  to  the 
healthcare  informatics  domain.  Funded  by  the  National  Library  of  Medicine, 
CERC  is  developing  a  pilot  healthcare  information  system  that  will  integrate 
the  latest  developments  in  multimedia,  networking,  and  user  interfaces  to 
provide  shared  access  to  multimedia  patient  records,  and  to  enable  remote 
consultation  among  participating  state  medical  facilities. 
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Miscellaneous 


MESSAGES: 

Messages  for  participants  of  the  forum  can  be  left  at  the  CERC 
switchboard:  (304)  293*7226 

All  messages  will  be  posted  outside  the  door  to  this  room 
PARKING: 

Ignore  the  “parking  decal  required”  signs  -  the  WVU  parking  authority 
has  been  notified  not  to  ticket  cars  parked  at  the  CERC  facility 

ASSISTANCE: 

For  help  or  assistance  at  any  time,  contact  the  seminar  support  staff 
(red  ribbons) 

LUNCH: 

Will  be  served  on  the  fourth  floor 

There  will  be  a  box  available  tor  depositing  the  $10.00  to  cover  food 
and  beverage  costs 
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8.-00  AM 


Seminar  Schedule  16  November 

Seminar  Logistics  -  Charlie  Snyder 


8:10  AM  CERC  Welcome  -  Dr.  Ramans  Reddy 

8:20  AM  CARDS  Welcome  -  Bob  Lencewicz 

8:30  AM  Why  Architectures?  -  Charlie  Snyder/Kurt  Wallnau 

9:15  AM  Break 

9:25  AM  Senses  of  Architecture  •  Paul  Kogut/Kurt  Wallnau 

10:35  AM  Break 

10:45  AM  Software  Architectures  and  Reuse  -  Wallnau/Kogut 

1 2:00  AM  Lunch  -  4th  Floor  Antechamber 
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Seminar  Schedule  16  November  -  continued 


1 :00  PM  Case  Studies  of  Reuse  Systems  -  Kogut 

2:15  PM  Break 

2:25  PM  CARDS  use  of  Architectures  -  Nancy  Solderitch 

3:05  PM  Break 

3:15  PM  Panel  Session  -  Architectures  in  Practice 

T.  Saunders,  Mitre 
H.  Polzer,  Unisys 
S.  Levine,  CECOM 
F.  Swartz,  Air  Force  ASC/YTE 

5:00  PM  Summary  and  Closing  Remarks 

5:30  PM  CERC  Demonstrations  and  Tour 
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Architecture  Forum  Workshop  - 17  November 


Purpose: 

•  Explore  the  current  practice  of  software  architectures  and  software  re¬ 
use  on  actual  projects 

•  Explore  current  research  Into  architecture  as  a  means  of  implementing 
reuse 

Overview: 

•  Morning: 

•  Short  presentations  by  practitioners  and  researchers  on  their  current 
work  with  architectures 

•  Afternoon: 

-  Working  session  to  identify  common  problems  in  reuse 
implementation  and  develop  a  common  approach  to  solutions 


Workshop  Schedule  17  November 


8:00  AM  Transitioning  from  research  to  practice  -  T.  Saunders,  Mitre 

8:30  AM  Architecture  as  the  framework  for  realizing  the  benefits  of  reuse 

-  W.  Tracz,  IBM 

8:45  AM  Abstraction  and  layering  within  software  architectures 

•  M.  Gerhardt,  ESL 

9:00  AM  Overview  of  DiSA  Software  Reuse  Domain  Analysis 

•  D.  Gary,  DISA 

9:15  AM  Software  Architecture,  Reuse,  and  Maintenance 

•  Jim  Baldo,  Unisys 

9:30  AM  Break 

9:45  AM  The  Object-Connection-Update  Architecture 

-  Charles  Plinta,  ACCEL 
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Workshop  Schedule  1 7  November  -  Continued  jj 

10:00  AM 

PRISM  software  architecture  •  P.  Valdez,  ESC/ENS 

10:15  AM 

NSA  Unified  INFOSEC  Architecture  (UIA)  -  B.  Koehler,  DIRNSA 

10:30  AM 

9LV  Mk3  shipboard  C2  architecture  •  U.  Oiason,  CelsiusTech 

Systems 

10:45  AM 

Architectures  and  the  real  world,  based  on  the  Army  C2 
common  eoftware  program  experience  -  S.  Levine,  Army 

11.-00  AM 

Break 

11:15  AM 

Architectures  in  the  CIS  field  -  applying  Christopher  Alexander’s 
work  -  J.  Bonine,  Design  Metrics  Technology 

11:30  AM 

OO-based  architecture  use  at  NUWC  -  S.  Rood  been,  NUWC 

11:45  AM 

Capturing  domain  knowledge  at  NTF  -  T.  Gill,  NFT/ENS 
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Workshop  Schedule  17  November  -  Continued 

1 2:00  PM  STARS  demo  project  architecture  -  G.  Wickman,  CECOM 
12:15  PM  The  STARS  Air  Force  Demo  Project  -  K.  Spicer,  SWSC/SMX 
12:30  PM  Lunch  -  4th  Floor  Antechamber 

1 :30  PM  Working  Groups 

4:30  PM  Working  Group  Report 

5:00  PM  Wrap-up 
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Proposed  Working  Groups  and  Topics  - 17  November 

WQ  1:  Evaluation  and  Msaamwiiant  of  AnchHacairta 

-  pcocurwmm  tew;  how  on  many  propo— d  nWHdw—  bs  ivlufd? 

•  design  Issues:  what  are  the  “archltecture-aveT  qualtles  which  can  and  should  be 
measured? 

WO  2:  Software  Architecture  Technologies 

what  are  the  current  and  emerging  technologies  tor  software  architecture? 

•  wham  Is  the  “tow  hanging  *idr  (La*  easily  attained  but  useful  technology)? 

WQ  S:  Software  Architecture  and  Reuse 

•  wti«dOMltmMnfor«na(ctift«cluratt>b«“miMbl«r' 

•  what  to  needed  lof  product-tin*  architectures  to  sustain  ■  commercial  component 
provider  Industry? 

WQ  4:  Software  Architecture  and  Standards 

wtMt  Is  the  isiattonehlp  between  architecture  ind  opsn  systems? 

•  what  are  areas  of  architecture  standanliaaon,e«*  “bulling  codes?” 

WQ  S:  Software  Architecture  and  Strategic  (Product-Une)  Planning 

>  wtiara  In  tha  DoO  ahould  architectures  ba  specified?  malntalnad?  Implamantad?  What 
am  tha  proa/cons  of  various  approaehas? 

•  how  can  DoD  architectures,  It  specified,  t>a  uaad  preacrtpdvety  In  procuring  systems 
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Forum  Evaluation  Form 

Please  take  a  few  minutes  at  the  end  of  the  forum  to  complete  the  evaluation 
form  provided  in  your  handouts. 

We  need  your  comments  to  improve  our  seminars  and  ensure  that  their 
contents  are  relevant  and  timely  to  the  software  reuse  community. 

Any  comments,  suggestions,  or  criticisms  are  solicited,  either  attach  them  to 
the  evaluation  form  or  contact  either: 

Charlie  Snyder,  Forum  Coordinator,  (304)  363-1731,  snyder@cards.com 
or 


Kurt  Wallnau,  CARDS  System  Architect,  (304)  363-1731,  wallnau@cards.com 


Dr.  Reddy 


Or.  Ramana  Reddy  is  a  Professor  of  Computer  Science  and  the  Director  of 
the  Concurrent  Engineering  Research  Center  (CERC)  at  the  West  Virginia 
University.  At  CERC,  Dr.  Reddy  leads  the  development  into  enabling 
technologies  for  concurrent  engineering.  He  has  achieved  significant 
research  results  in  multimedia  communications,  constraint  management, 
uncertainty  reduction,  and  knowledge-based  systems. 
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A  Natural  Continuation  of  Current  Work 

Software  Architecture  is  a  topic  of  considerable  interest  to  practitioners  and  researchers  in  the  academic, 
government,  and  commercial  software  areas. 

Why?  Why  now? 

What  is  the  relevance  to  an  organization  trying  to  improve  its  software  development  capability? 

How  does  architecture  relate  to  the  other  software  development  improvement  concepts  of 
Software  Process  Improvement  -  SEI CMM 
Total  Quality  Management 
Metrics  and  Statistical  Process  Control 
STARS  Megaprogramming 
Domain  Analysis  and  Domain  Engineering 
Library  based  Reuse 
Object-Oriented  Analysis  and  Design 

Many  of  the  research  topics  and  implementation  efforts  seem  inevitably  to  lead  to  the  study  of  software 
architectures.  This  seems  to  stem  from  the  continual  human  endeavor  of  always  trying  to  generalize  and 
conceptualize  from  a  specific  instance  to  a  more  general  case. 

We  believe  that  the  current  interest  in  software  architectures  represents  the  natural  evolution  of  the  histor¬ 
ical  focus  on  changing  software  development  from  a  craft  to  an  engineering  discipline. 
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Why  do  we  need  Software  Architectures ? 


Greater  Cost  Savings 


Why  do  we  need  Software  Architectures? 

There  are  many  forces  at  work  leading  research  and  implementation  efforts  into  considering  architectures 
as  an  area  of  major  payoff  in  software  development  improvement  Some  major  ones,  and  their  implications 
are  listed  below: 

•  Reuse  of  Analysis  &  Design  -  The  higher  level  at  which  the  artifacts  are  reused,  the  greater  the 

payoff. 

•  Systems/Hardware  issues  -  System  performance  and  hardware  capabilities  often  determine 

the  software  ctejign 

•  Difficulties  in  Implementing  Reuse  -  Reuse  of  other  than  minor  code  modules  is  very  difficult 

because  reuse  ts  typicaly  considered  after  system  design 
decisions  have  been  made. 

•  Need  for  long-lived  systems  -  Systems  must  be  enhanced  as  new  technologies  appear. 

•  Need  for  adaptability  -  Longer  lived  systems  have  to  change  to  meet  situations  not 

envisioned  when  they  were  developed 

•  Increased  emphasis  on  standards  -Systems  now  must  conform  to  various  interface  standards 

and  often  development  standards  that  require  interface  to  a 
variety  of  existing  COTS  software. 

•  Life-cycle  Maintenance  Issues -Software  systems  that  use  COTS  and  open  standards  are  easier 

to  maintain  than  custom  developed  software. 

•  Greater  Cost  Savings  •  Reuse  and  developing  software  using  large-scale  existing 

components  promises  to  significantly  reduce  development  cost. 

Those  savings  have  been  historically  difficult  to  achieve. 
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Why  not  before  Now? 

Dtv«rM  DMlgn  Approach**  -  Structured  OMlgn,  OOD 
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Why  not  before  Now? 

Architecture  has  just  reoenfly  bscoms  •  focus  of  study  by  ths  reuss  community.  Whie  a  major  reason  for  this  just  occurring  is  the 
increased  emphasis  on  recognizing  patterns  in  domain  engineering  and  other  reuse  activities,  there  are  other  forces  serving  to  inhibit 
architecture  engineering: 


•  Diverse  Design  Approaches  ■ 


•  Diverse  Applications  - 


•  Diverse  Languages  - 


•  Lack  of  Standards  - 

•  Lack  of  Quafty  Standards 


The  myriad  of  design  methodologies  inhbits  a  recognition  of  common  structure.  And 
how  can  you  reuse  C++  classes  in  a  structured  design  developed  system? 

Practitioners  consider  each  application  domain  as  unique  and  unable  to  share  with 
other  outside  domains.  Thus  the  real-time  practitioners  and  the  MIS  community 
continue  to  evolve  in  separate  ways. 

While  code  IncompatibiSties  are  obvious,  many  times  the  choice  of  language  dictates 
the  design  in  subtle  ways.  This  is  most  obvious  with  C++  and  ofherOO  languages,  but 
Assembly  Language  also  scopes  the  design  choioes  available 

Standards  define  the  boundaries  and  limits  on  the  design.  Without  standards,  there 
are  no  BmJte— every  new  system  is  a  complete  new  challenge. 

How  can  the  choice  be  made  between  several  designs  and  approaches  without  some 
standard  defining  the  quaity  of  the  product  Software  development  is  just  beginning 
to  have  such  a  standard. 


•  No  Guiding  Engineering  DiscpSne-  Software  engineering  lacks  the  theoretical  base  of  other  engineering  dwcjpiines,  N  is 

currently  more  a  craft 

•  Companies  have  dfflerent  goals  -  Consider  a  fuf  fixed-price  contract  (FFP)  vs.  a  cost  plus  fixed  fee  eontract(CPFF). 

There  is  no  incentive  for  the  contractor  to  control  software  costs  on  the  CPFP  contract. 
Government  auditors  often  disallow  costs  savings  measures  on  (he  FFP  contract  In 
all  cases  the  benefits  from  controlling  costs  to  the  contractor  are  somewhat 
nebulous— the  contractor  wants  to  win  new  business  as  the  major  goal. 

•  Requires  a  Paradigm  Shift  -  Just  as  with  the  concept  of  Software  Process  Improvement,  reuse  requires  a  major 

change  in  organization  for  a  company.  Software  now  must  be  understood,  made  an 
Item  of  capital  investment,  and  must  be  managed.  But  many  managers  come  from 
hardware  or  business  areas  and  have  no  understanding  of  or  Interest  in  software 
development 


The  Goal  of  the  Seminar 


To  use  architectural  concepts,  we  must  understand • 

•  the  various  meanings  of  software  architecture 

•  the  current  research  in  the  field  of  architecture 

•  current  efforts  in  applying  software  architecture 


These  and  other  concepts  will  be  explored  during  the 
remainder  of  this  seminar. 
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The  Goal  of  the  Seminar 


The  remaining  sessions  wil  explore  software  architectures  and  the  usefulness  of  the  concept  lor  imple¬ 
menting  software  reuse. 


Some  Cautionary  Thoughts  Before  Proceeding 


Exercise:  Define  the  concept  “Game" 


No  matter  what  you  try,  you  will  define  a  conceptual 
category  which: 

—  includes  something  which  should  be  excluded 

—  excludes  something  which  should  be  included 

Intensional  definitions  do  not  work  well  with 
abstract  conceptual  categories 


Some  Cautionary  Thoughts  Before  Proceeding 


This  example  illustrates  an  old  trick  phiosophy  prolessors  play  on  students— setting  up  definitions  only  to 
knock  them  down  again.  As  it  turns  out,  there  are  sound  reasons  why  this  trick  "Vwxksr  where  fairly  abstract 
concepts  are  concerned,  as  revealed  by  researchers  in  cognitive  psychology. 

The  bottom  line  is  that  understating  what  forms  a  cognitive  category  is  no  mean  feat. 

References 
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Architecture  as  a  Conceptual  Category 


Categories  are  formed  from  experience 


fj maS™11*  language  analnM>r 

tneonst  system  engineer 
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Architecture  as  a  Conceptual  Category 

Given  that  we  form  conceptual  categories  based  upon  our  own  experiences  (we  can  assume  this  propo¬ 
sition  for  the  purposes  of  the  seminar,  even  though  this  theory  is  by  no  means  universally  held  as  "truth 
revealed"),  it  should  not  be  surprising  that  a  number  ol  different  perspectives  on  the  topic  of  software  ar¬ 
chitectures,  and  domain-specific  software  architectures  and  reuse,  have  emerged. 

Quite  apart  from  the  natural  tendency  in  the  research  community  to  reward  ‘innovative’  and  ‘unique’  ap¬ 
proaches  (which  tends  to  generate  approaches  which  have  commonality  well-concealed  beneath  layers  of 
obscure  terminology),  there  is  also  a  natural  tendency  to  stress  what  is  important  in  a  category  based  upon 
personal  experiences  and  personal  needs. 

The  chart  ilustraies  a  number  of  difierent  perspectives  which  might  lead  to  a  number  of  different  interpre¬ 
tations  about  what  constitutes  the  most  central  concept  in  the  architecture  category.  Naturally  no  attempt 
has  been  made  to  enumerate  all  roles  or  all  definitions/concepts  tor  the  architecture  category,  nor  is  it  im¬ 
plied  that  one  perspective  is  only  narrowly  interested  in  one  concept  (that  is  what  is  implied  by  “most  central 
member). 


>1  Smattering  of  Software  Architecture  Definitions 


A  Smattering  of  Software  Architecture  Definitions 

In  times  of  crisis,  however,  we  can  find  comfort  in  definitions  There  are  a  number  of  definitions  of  software 
architecture  found  in  the  literature  (this  list  is  not  meant  to  be  complete).  The  definitions  usually  reflect  the 
perspective  of  the  author  (e.g.  Lowry  has  an  AJ  perspective).  Note  that  in  some  cases  a  single  author  wil 
have  several  dHferent  tensed*  ol  the  term.  Penry  and  Wolf,  for  example: 

"We  use  the  term  ‘architecture' to  Invoke  notions  of  abstraction,  of  standards,  of  formal  training 
(of  software  architects),  and  of  style.’ 
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Fundamental  Principles  of 
DoD  Reuse  Vision  and  Strategy 

Domain  Specific  Reuse 

Process  Driven  Reuse 

Architecture-Centric  Investment 


Interconnected  Reuse  Libraries 


CARDS  Context 


The  CARDS  program  is  one  member  of  a  larger  DoD  Software  Reuse  Initiative.  The  other  member  pro¬ 
grams  include  the  DISA/CIM  software  reuse  program,  and  the  STARS/ASSET  program.  These  three  pro¬ 
grams  provide  cooperative,  complementary  coverage  of  the  field  of  software  reuse  to  help  transition  the 
techniques  and  technologies  of  reuse  into  practice. 

Each  of  the  programs  are  guided  by  the  DoD  Software  Reuse  Vision  and  Strategy.  The  four  fundamental 
principles  of  the  Vision  and  Strategy  are  listed  on  the  left  of  the  slide. 

The  CARDS  program  is  interested  in  evaluating  and  transitioning  reuse  technologies  which  bring  together 
the  concepts  of  software  architecture,  domain-specific  reuse  and  reuse  fibraries.  As  wit  be  seen  in  a  later 
presentation  (Session  V).  CARDS  is  pursuing  an  advanced  technology  approach  to  fuse  these  concepts: 
our  Kbrary  technology  is  based  on  knowledge-representation  formaSsms  which  help  us  represent  software 
architectures  and  provide  automated  reuse  assistance  based  on  architecture  models  and  a  library  of  soft¬ 
ware  components. 

This  is  one  reason  why  CARDS  is  so  actively  interested  in  the  state  of  research  and  the  state  of  practice 
in  the  field  of  software  architecture. 
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The  Topic  Transcends  Technology 


Standardization  Issues 


Business  Issues 


Procurement  Issues 


Reuse  Issues 


The  Topic  Transcends  Technology 

The  convergence  of  business,  policy,  and  technology  must  be  a  consideration,  as  wel  as  differentiating 
architecture  technology  from  reuse  technology.  CARDS,  to  be  successful,  needs  to  have  a  sufficiently 
breed  technical  foundation  to  express  the  trends  of  architecture  and  domain-specific  architecture  methods 
and  technologies  in  order  to  help  guide  the  formulation  of  business  and  acquisition  models. 


CARDS  Cross  Section  of  Ideas 


Logistic  Center 


Commercial  Tool 
Providers 


Industrial  R&D 
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CARDS  Cross  Section  of  Ideas 

Good  ideas  or  the  topic  of  software  architecture  are  not  emerging  only  from  research  programs.  In  a 
sense,  the  image  of  a  technology  pipeline  is  inaccurate— a  better  image  might  be  a  series  of  technology 
sprinklers: 

•  basic  research:  tteory,  concepts,  taxonomies  of  architectures. 

•  applied  research:  experimental,  proof-of -concept  technologies 

•  advanced  technology  demonstrations:  demonstrations  of  scale-ability 

•  ongoing  development  programs:  transition  issues 

•  logistics  and  support  programs:  retro-fitting,  reverse  engineering,  integration  and  test 


The  motivation  fa  this  seminar,  and  especially  me  follow-up  workshop,  is  to  help  the  CARDS  program  to 
cut-acro6s  these  boundaries,  to  identify  a  broad  cross-section  of  ideas  on  software  architectures.  In  turn, 
CARDS  hopes  to  use  this  knowledge  to  help  accelerate  the  transition  of  good  ideas  into  practice,  as  wen 
as  provide  feedback  to  research  and  development  efforts  into  the  perspectives  of  practicing  engineers. 


Category  Building  Context  Setting 


Anatomy  of  this  Presentation 


This  chart  depicts  a  more  detailed  anatomy  of  the  seminar,  with  the  size  ot  each  session  block  in  rough 
scale  to  the  time  allotted. 

The  top-level  structure  o!  the  seminar  are: 

•  Session  I:  Context  setting 

•  Session  II:  Building  a  conceptual  category  fa  software  architecture 

•  Session  III:  Synthesizing  session  II  into  a  working  model  of  software  architecture,  and 
extending  our  focus  into  kinds  of  software  architectures  and  architecture- based  reuse 
systems 

•  Session  IV:  A  survey  of  architecture-based  reuse  systems 

•  Session  V:  A  short  overview  of  what  CARDS  is  currently  doing,  relative  to  software 
architecture 

•  Session  VI:  A  panel  discussion  on  the  practical  concerns  of  adopting  software  architectures 
in  the  DoD— which,  hopefully,  wil  reveal  interesting  issues  and  ignite  interesting  discussions. 

Tomorrow,  of  course,  is  a  workshop  where  we  can  continue  the  discussions,  and  continue  to  exchange 
ideas. 
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Roadmap  for  this  Session 

Architecture:  MuHI-Dlsctollnarv  Overview 


sar  Manufacture  Perspective 
Engineering  Perspective 
Architecture  Perspective 


•  production  dtodplbw  and  automation 

•  MerohangeaMe  pan*  and  assemblies 

•  prooffi  contra 


•  engineering  dtodpMne 

•  codified  knowledge  In  engineering  models 

•  predtetable  results  through  composition 


•  dsalgn  dtodptns 

•  (am  and  context:  bounds  on  creativtty 

•  design  patterns  and  "style" 


Software  Architecture:  Overview 


Scientific  Foundation 
Engineering  Application 
Considerations  in  Practice 


_  •  Identification,  classification,  description 

•  abstraction  and  analysis 


•  abstract  and  concrete  models 
*»•  •  engineering  and  production  technlquea 


•  strategic/business  considerations 

•  policy  Issues 

•  economic  Issues 


Roadmap  for  this  Session 

Our  approach  is  to  take  two  tacks  on  tie  subject. 


Fast  we  examine  architecture  from  a  broader  perspective,  stepping  outside  of  the  "computer  science*  dre- 
dpline.  The  objective  of  taking  a  multi-disciplinary  perspective  to  start  with  (Imbed  as  H  is)  is  to  establish 
some  reasonable  analogies  as  a  basis  for  further  elaborating  the  characteristics  o*  the  emerging  discipline 
of  software  archHechxe  and  engineering.  We  look  at  three  perspectives: 

1)  Manufacture  —  how  do  architectures  relate  to  the  production  discipline. 

2)  Engineering  —  how  do  architectures  relate  to  engineering,  i.e.,  problem-solving  disdpfines 

3)  Design  —  how  do  architectures  relate  to  the  design,  i.e.,  creativity,  disciplines 

We  take  these  perspectives  since  so  much  of  the  discussions  about  software  engineering  are  biased  by 
points  of  view  related  to  these  perspectives  (How  to  put  the  engineering  in  software  engineering*  Trow  to 
support  reuse  of  designs*  *we  need  more  engineering  and  less  creativity,"  'component  factories,*  etc.) 

After  establishing  our  analogy  basis,  we  provide  a  high-level  overview  of  some  of  the  current  approaches 
directly  relevant  to  software  architectures.  Again,  we  take  three  perspectives: 

1)  Scientific  —  the  study  of  software  architectures  in  their  own  right 

2)  Engineering  —  the  development  of  product  models  and  production  models  based  on  architecture 

3)  Transition  to  practice  —  the  organizational,  economic  and  policy  considerations 
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The  Industrial  Revolution 
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Industrial  Revolution 

Before  the  industrial  revolution,  the  production  of  goods  and  services  was  done  in  cottage  industries  where 
labor  was  cheap  and  materials  were  expensive,  (notice  that  in  software  labor  is  expensive  and  materials 
—computer  resources— are  now  cheap,  hi  a  cottage  industry  each  part  was  made  tram  raw  materials  (soft¬ 
ware  analogy  -  source  code),  and  hand  fit  to  an  assembly  (unique  software  design).  Then  testing  was 
done  and  parts  would  be  further  adjusted  (integration). 


In  the  late  1 700‘s  the  US  Government  looked  tor  a  better  way  to  manufacture  rifles.  The  idea  was  to  build 
standard  interchangeable  peris  which  could  be  assembled  into  a  rifle  (a  domain  specific  architecture).  The 
key  facilitating  idea  (**1820)  was  that  a  measurement  procedure  and  tool/gauge  was  used  to  determine 
conformance  to  a  specification  within  a  certain  tolerance  (qualification  process).  It  took  24  years  for  this 
‘armory  practice*  to  be  adopted  tor  commercial  products  (technology  transition) 
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Build  to  Order 


Build  to  Order 


Ideas  from  manufacturing  processes  were  then  later  adapted  to "build  to  order*  products  tike  plumbing  sys¬ 
tems  (which  aie  more  tike  software  systems).  In  "buid  to  order  there  are  generic  parts  such  as  valves  and 
pipe  segments  which  have  limited  ways  of  interconnecting,  are  made  of  only  certain  kinds  of  materials,  and 
are  available  in  only  a  certain  set  ol  standard  sizes. 

The  "build  to  order  perspective  most  closely  resembles  component-based  programming — i.e.,  program¬ 
ming  with  higher-level  abstractions/bulcing  blocks.  The  ARPA/ProtoTech  project  provides  one  view  olthis 
kind  of  programming  model,  as  reflected  in  some  of  the  focus  ProtoTech  has  on  module  interconnection 
languages  (MB.)  and  tormaisms  (MIF).  The  idea  of  MIFs  is  to  provide  some  standard  interconnection 
mechanisms  as  a  way  tor  components  to  be  assembled.  Note  that  the  separation  of  coordination  from  form 
is  not  a  ursversaKy-heid  prerequisite  tor  component-based  programming. 

What  is  most  interesting  in  this  discussion  is  that  "build  to  order  need  not  require  an  architecture— there 
are  some  who  befieve  that  tor  specific  application  areas  in  software,  e.g.,  information  management  sys¬ 
tems.  that  build-to-order  based  on  large  component  chunks  may  be  more  appropriate  than  a  refine-able 
design  solution. 

The  idea  of  separating  the  interconnection  and  coordination  mechanisms  from  the  component  (or  the 
Tomf)  is  an  idea  which  wil  recur  later. 
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Design  Reuse  in  Chemical  Engineering 


The  three  main  farititators  ot  design  reuse  in  chemical  engineering  are  handbooks,  published  processes 
(architectures),  and  corporate  design  standards.  These  are  all  based  on  empirical  observations,  scientific 
theory,  and  economics.  We  will  look  at  these  three  facilitators  in  more  detail. 
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Handbooks 


Chemical  Engineering 

•  One  main  handbook  for  the  entire 
field 

•  Comprehensive  coverage  of  unit 
operations 

•  Patterns  of  unit  operations 

•  numerous  heuristics 

•  over  100  authors 

•  emphasis  on  economics 

•  common  language  -  math  and 
chemistry 


Software  Engineering 

•  Fragmented  set  of  hand¬ 
books 

Incomplete  coverage  of  com¬ 
ponents/algorithms 

•  Few  patterns 

•  some  heuristics 

•  One  or  a  few  authors 

•  processing/memory 

•  proliferation  of  languages 
and  design  notations  -  Ada, 
C,  C++,  Booch... 
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Handbooks 


The  one  main  chemical  engineering  handbook  has  more  breadth  and  depth  #tan  existing  software 
engineering  handbooks  (because  the  field  is  more  mature).  Unit  operations  (e.g.  a  heat  exchanger,  a 
cfistiBation  column)  are  the  basic  components  in  chemical  engineering.  A  category  of  unit  operations  (e  g 
heat  exchangers)  tonne  a  horizontal  domain  (analogous  to  search  algorithms  or  DBMSs  in  software). 
Mo6i,  but  not  all,  software  engineering  handbooks  deal  with  small  grained  components/algorithms  (vs. 
large  grained  components  like  DBMSs)  that  are  at  a  lower  level  of  abstraction  than  unit  operations. 

Chemical  engineering  handbooks  give  patterns  of  how  to  put  unit  operations  together  in  a  process  (see 
next  slide).  This  is  an  important  distinction.  Software  engineering  is  just  beginning  to  capture  and  organize 
a  wide  range  of  information  about  patterns.  Patterns  in  software  may  be  more  difficult  to  capture  and 
organize. 


It  is  interesting  to  note  that  the  amount  of  expertise  needed  for  a  comprehensive  chemical  engineering 
handbook  makes  a  large  number  of  authors  necessary.  Also,  the  chem.  eng.  handbook  emphasizes 
economics,  whereas  many  software  eng.  handbooks  only  address  processing/memory  resources. 
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Patterns  -  Example:  Liquid  Extraction  Systems 


This  side  shows  a  good  example  of  what  is  meant  by  patterns  of  unit  operations  (components)  that  are 
contained  in  the  chem.  eng.  handbook  (right  side  of  slide  is  actuary  the  top).  A  discussion  oi  heuristics  and 
design  trade-offs  related  to  these  patterns  is  also  found  in  the  handbook. 


Reference:  Peny,  Chilton,  “Chemical  Engineers'  Handbook",  5th  ed.  1973 
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Published  Processes 


fifi 

•  Generic  Industrial  processes  (architectures)  are  published  in: 

-  handbooks 

-  Journals 

-  patents 

•  Processes  include: 

•  constraints  on  choice/placement  of  unit  operations 

-  material  flows 

•  control:  temperature,  pressure,  timing... 

•  Design  steps: 

-  refine  generic  process  based  on: 

-  production  rates 

-  product  and  raw  material  specifications 

-  do  detailed  design  of  unit  operations 

-  evaluate  plant  design  by  simulation/calculate  return  on  investment  77 
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Published  Processes 


In  ehern  eng.,  industrial  processes  for  producing  chemical  products  are  pubished  more  frequently  and  in 
more  detail  than  in  software  engineering  (note  Industrial"  -  many  pubfched  system  designs  in  software 
eng.  are  research  prototypes).  There  is  a  widely  known  published  catalog  ol  processes  that  covers  the 
entire  spectrum  of  chemical  process  industries  (I  know  of  no  equivalent  tor  software  eng  -  there  are  books 
that  look  at  generic  designs  of  one  specific  application  area  •  e.g.  compilers).  Patenting  a  detailed  chem. 
eng.  process  is  common  practice. 


Notice  the  analogy  of  what  a  published  chem.  eng.  processes  indudes  to  what  is  inducted  in  a  software 
architecture  (e  g  constraints  on  choice^lacement  of  components,  data  tftw,  and  control  information 
(control  is  a  major  subfield  ol  chem.  eng.).  See  next  side  for  an  example  of  a  published  process.  Also 
notice  the  analogy  of  refining  a  generic  design/architecture  based  on  detailed  requirements.  This 
emphasizes  the  engineering  mindset  of  composing  solutions  fro m  pest  experience.  Notice  the  tack  of 
emphasis  on  calculating  the  return  on  investment  for  a  software  engineering  design.  Evaluating  the 
composed  system  before  it  is  built  is  also  port  of  the  engineering  mindset. 


?e 


Reference:  Shreve,  Brink  “Chemical  Process  Industries’,  4th  ed.  1977 


Published  Process  -  Example:  Alcohol  Distillation 


6485*C 


C,H,OH  18.5% 

CJh|  74.I%H - 

HjO  74% 


Feed 
-2H50H  960% 


|  Condenser  Seporotor 
20!  C. 

*  8 


H20 


Steam 


W  18.5% 
74.1% 
7.4% 


pS4.85°C. 

I  Condenser 


4.0% 


78i®C. 


100% 


IT 


Aqueous 
alcohol 

CgKjOH 


96.0% 

4.0% 


Separator  Equilibrium 

Top  layer  Bottom  I oyer  Steam 
Vol.%  Overhead  84.0  16.0 
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■Ar- 


C2H30H 
C«H  * 
k^O 


14.5%, 

84.5 

1.0 


53.0% 
1 1.0 
36.0 


_ 

Published  Process  -  Example:  Alcohol  Distillation 

Notice  the  choice  and  Me  nnections  (architecture)  of  unit  operationB  (component  types),  the  material 
flow  (data  flow),  and  the  te.  aratunes  (control  information).  Notice  that  each  unit  operation  is  treated  as  a 
black  box  (except  the  separator)  so  there  is  Bextrtity  in  choosing  the  sae  and  exact  internal  design  tor  the 
actual  equipment  (impiementafon  components). 

References:  Perry,  Chiton  “Chemical  Engineers'  Handbook”  5th  ed.  1973 
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Corporate  Design  Standards 


s 

•  Management  commitment  to  design  reuse 

•  Captures  and  organizes  experience/knowledge  of  corporate  engineers 

•  Design  standards  include: 

•  specific  design  equations 

•  heuristics  for: 

-  design  criteria  for  equipment  “Avoid  thin  wail  tubes” 

-  parameter  estimation 

•  example  calculations 


•1 


Corporate  Design  Standards 


These  chem.  eng-  corporate  design  standards  go  beyond  handbooks  in  helping  to  design  unit  operations 
(horizontal  domains).  These  standards  are  used  along  with  published  processes  (architectures)  which  are 
often  supplemented  by  proprietary  details.  Can  you  imagine  a  set  of  corporate  standard  software 
components  used  in  all  systems  across  all  application  domains? 
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How  Does  This  Apply  to  Software  Architecture? 

•  How  Is  community  knowledge  represented  and  shared? 

•  What  are  the  architectures  (product  models)? 

•  What  are  the  design  processes? 

•  How  does  management  demonstrate  commitment  to  design  reuse? 


TNb  page  intentionally  left  btai*. 


Roadmap  for  this  Session 


Architecture;  MuHl-DlscIpHnarv  Overview 


Manufacture  Perspective 
Engineering  Perspective 
tar  Architecture  Perspective 


•  production  Wsdpllne  and  automation 

*  •  interchangeable  parta  and  assemblies 

•  procaai  control 

« engineering  dtodpina 

“  •  cooHlad  knowledge  in  engineering  modaka 

•  prsdfctabte  raauita  through  composition 

•  daaign  dUdpdna 

*  •  torn  and  context:  bounds  on  creatMty 

•  design  patterns  and  “style" 


Software  Architecture:  Overview 


Scientific  Foundation 


.  •  identification,  classification,  description 

*■“  •  abstraction  and  analyals 


Engineering  Application 


•  abatract  and  concrete  modela 

•  engineering  and  production  techniques 


Considerations  in  Practice 


•  strategic/business  considerations 

•  policy  Issues 

•  economic  Issues 

as 


This  page  intentionally  left  blank. 


Obvious  Analogies 

Clwmical  Arshltegtlllfl  Software  Architecture 


Blueprints,  etc.: 

•  plan,  elevation, 
perspective 

•  drawings/modets, 
architect  plans, 
shop  plana 


Design  Representations: 

•  multiple  views 

•  models  for  differentiated  roles 
(customer,  system  engineer, 
software  engineer) 


Architecture  styles: 

•  Romanesque, 

•  Gothic 

•  Victorian 


Architecture  styles: 

•  Distributed 

•  Client/Server 

•  Layered 


Constraints: 

•  circulation  patterns 

•  acoustics 

•  airflow 

•  lighting... 


Constraints: 

•  timing  and  schedules 

•  reliability  and  fault  tolerance 

•  performance  and  throughput 

•  data  management  and  distribution 


Obvious  Analogies 

Much  has  been  made  of  the  analogies  between  software  architecture  and  classical  (or  "building')  architec¬ 
ture.  Some  obvious  analogies  have  been  made  between  design  notations  used  by  software  architects  and 
beading  architects;  other  analogies  have  been  drawn  between  architecture  idioms  and  recurring  patterns 
of  software  designs. 

However,  these  analogies  are  of  limited  utiSty.  For  example,  any  dndpine  requiring  problem  solving  where 
the  information  space  relevant  to  the  successful  solution  exceeds  human  short-term  memory  will  involve 
specialized  notations.  This  is  also  the  case  where  multiple  partes  are  involved  in  problem  solving  and  pro¬ 
duction,  in  which  case  numerous  specialized  notations  may  be  used. 

Less  obvious  analogies  can  be  drawn  between  toe  classical  architecture  and  computer  systems  which  are 
more  revealing  For  example,  after  centuries  ol  practice,  a  tew  key  families  of  constraints  have  emerged 
in  the  design  of  buidings,  eg.,  acoustics,  circulation  flow.  These  are  areas  of  potential  "misfits'  between 
a  design  problem  and  its  solution  (in  this  case,  a  building).  Simiarty,  in  computer  systems  a  number  of  fam¬ 
ilies  of  constraints  have  Hkewise  emerged— fault  tolerance,  security  and  human-machine  interlace  ergo¬ 
nomics,  for  example,  which  can  result  in  misfits  between  a  system  and  its  requirements. 

The  real  benefits  of  understanding  classical  architecture  as  a  precursor  to  studying  software  architecture 
is  the  relationship  between  classical  architecture  and  a  theory  of  design. 

References: 

Cnrwopht'  Alsxandsr.  Notts  or  ttM  Svmr>«sg  ol  Form  Harvard  UnNarsity  Prats  1964  ISBN  0-674-62750-4 

Dawaynt  Parry.  Wot.  L.  'Foundations  lor  ttw  Study  ol  Softwara  AreWtaauta.'  Softwsrs  Enginssnng  Notts  VU.17  No  4.  Oct.  1992 

Zactvnan.  J  .  "A  Framawor*  lor  Information  Systams  Arctmacwra.'  IBM  Sy*tms  Journal  Vot  26.  No  3. 1967 
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Classical  Architecture  Perspective  on  Design 


•  Quotee  from1  on  the  nature  otdeaign 
problema: 


•tout  nqdramanta  and  that 
to  ham  to  hantMa,  t  » 
dUuaa,  tawtganlead-Jha 
quantity  of  Information  ttaatt  a  now  bayonet 
tw  ranch  o(  arrgta  daatgnara  [and)  vanoua 
who  ratal  a  an  narrow  and 


untamhar  wth  tha  form  makari i  pan  War 
probtama. 


Tha  avaraga  daaignar  acana  whatawar 
Momwtten  ha  happana  on,  eon* uta  a 
eonsuHsntaaWhsn  laced  by  titni  epeciel 
d WouUaa,  and  Mmducaa  randomly 

-  -i  nH  .  , - r - 

•vw Mtew  iwniwon  vkd  tomip  oininNPV 

daamt  up  in  dm  arbata  atudto  ot  M*  nM 


A  a  -  -  *  -  —  *  J  m  M  1  •  aAMitetoMaMta 

(ypicv  praoMfn  • 

have  to  be  met,  and  there  are  Interactions 
among  tfw  requirements. 


*»»*-- - .  m  ->g.  ,  «-» - »- - 

AvWMrWVWmfM/IfilwniffKfNW 

fc  quMfy.  compkidty  end  ddhadty,  they 
else  change  letter  fun  before.  New 
materials  are  devefooed  at  Ihe  time  social 
pattama  altar  qutrMy,  tha  edtun  taaK  to 
changing  taatar  than  I  haa  mrar  changad 
baton. 
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Classical  Architecture  Perspective  on  Design 

Reading  an  overview  ol  the  design  prototem  which  Christopher  Alexander  is  addressing  is  Ike  reading  an 
introduction  to  softwarefeystenB  design  textbook.  Yet  these  are  problems  which  classical  architecture  has 
been  propping  with  lor  centuries. 

Reference:  Alexander,  C.,  Notes  on  the  Synthesis  ot  Form. 
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Why  Do  Architects  Introspect  on  the  Design  Process  ? 


T 

Materials  Properties, 
Social  Patterns,  etc. 


Desires  far  Artistic 
Bbimi  ton  end 
irefcvldual 
Recognition 


Perhaps  classical  architecture  represents  the  purest  example  of  a  discipline 
for  controlling  the  creative  design  process 


Architecture  is  considered  an  artistic  discipline  !n  addition  to  being  an 
engineering  discipline 


What  constraints  are  imposed  on  the  urge  for  spurious  creation? 


ft 


Why  Do  Architects  Introspect  on  the  Design  Promss? 

Pubic  introspection  is  an  important  port  o(  any  mature  protessionai  discipline:  it  is  what  mem  it  possible 
tor  a  community  ol  practitioners  to  evolve  the  state  o<  practice  within  a  discipline. 


The  (Ssdpline  of  classical  (or  “buiMing")  architecture  has  a  vast  body  ol  Sterature  which  de««  -vith  the  na¬ 
ture  of  design.  White  other  disciplines  attend  lo  the  study  of  the  design  process,  it  is  usually  w*ftin  the  coo- 
text  of  design  methods— procedures  and  notations  for  representing  and  transforming  the  wtjty  oroducts  of 
problem  solving.  Classical  architecture  addresses  these  “syntactic’  aspects  of  design,  too.  5k«t  the  disci¬ 
pline  also  has  a  rich  history  ol  design  theory  bordering  on  mysticism,  and  certainly  well  into  f s  realm  of 
meta-physics. 

This  is  probably  true  because  the  element  of  aesthetics  plays  a  more  overt  role  in  classics?  architecture 
than  in  engineering.  Thai  is,  wttito  one  may  attain  a  Zen-ike  appreciation  for  the  austere  wodongs  ola  DC 
motor,  such  devises  are  not  typically  afforded  appreciation  as  *worite  of  art*  This  is  certainly  the  case 
in  classical  archftecture,  where  a  tension  exists  between  the  need  to  engineer  a  solution  to  She  basic  hu¬ 
man  need  lor  shelter,  whle  simultaneously  satisfying  additional  cravings  tor  artistic  creation  and  individual 
distinction  and  recognition  which  accompanies  classical  architecture. 

Architects  study  design  because  their  problems  are  complex  and  1-formed,  their  solutions  must  satisfy  real 
needs  and  because  there  is  a  tendency  for  designers  to  engage  in  false  creativity,  non-esaer&ai  creation 
and  egotistical  design— all  of  which  interfere  with  achieving  useful  solutions. 
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The  Nature  of  Design:  The  Context/Form  Ensemble 


•  A  design  problem  consists  of  a  turn- 
part  ensemble:  a  problem  (context), 
and  a  solution  (form). 


we  do  not  control 
•  represents  the 
“problem" 


aw  cm  control 
•  represents  solution 

pfOOmtn 


and  complementary. 

•  Design  la  an  effort  to  achieve  “good 
fit"  between  form  and  context.  Fitness 
Is  a  relation  of  mutual  compatlbllty. 

•  It  la  Impractical  (perhaps  Impossible) 

compwtuy  wcnM  conitaci— w  n 
were  posaftte  there  would  be  no  de¬ 
sign  problem. 


How  does  this  apply  to  software  architecture  ? 


a  deelgn  problem  a 
problem  Is  that  we  are  attempting  to 
create  forms  for  contexts  we  do  not 
completely  understand  or  specify. 


•  Reuse  of  architecture  Implies  reuse  of  design 

•  Reuse  frequently  Implies  some  adaptation 

•  “Form"  of  design  depends  upon  complex  “ context "  Interactions 

•  Adaptation  of  the  form  (the  architecture)  makes  sense  only  “In  context’ 

•  Seen  In  DSSA/ADAGE,  ROSE-2,...  as  design  records,  design  rationale ~. 


_ 

The  Nature  of  Design:  The  Context/Form  Ensemble 

One  of  the  most  interesting,  and  useful,  ideas  which  emerge  from  Alexander  is  the  idea  of  a  design  en¬ 
semble,  something  which  consists  ol  boh  a  context  and  a  form  ss  inseparable,  complimentary  aspects  of 
the  design  problem. 

An  example  ol  the  complementary  nature  ol  confexVform  is  the  environment  and  a  biological  organism; 
natural  selection  is  the  mechanism  by  which  we  achieve  a  degree  of  fir  between  a  form  and  its  context 
(this  fit  is  called  *weH  adaptednessr). 

In  software  and  systems,  we  typicaly  refer  to  the  "context"  as  the  "requirements,’  and  the  form"  as  the 
"design."  The  term  "context  seems  better,  since  it  conveys  the  sense  ot  ensemble  better  than  does  the 
term  "requirements."  though  tor  most  intents  both  terms  are  equivalent. 

The  idea  of  a  complete  context/lorm  ensemble  may  seem  obvious  enough,  but  it  is  crucial  in  understarxing 
reuse  and  software  architectures.  It  wat  show  up  later  in  a  variety  ol  forms: 

•  component  ’’qualificalionr  is  a  measure  of  fir  between  a  component  and  its  context 

•  design  reuse  based  on  architecture  refinement  requires  the  encoding  of  context  information 
to  guide  the  refinement  process 

We  should  note  that  while  the  idee  of  a  complete  context/form  ensemble  makes  a  great  deal  of  sense,  in 
practice  software  and  system  "designs’  are  advertised  as  being  reusable  despite  the  fact  that  the  context 
which  produced  the  form  is  not  included,  has  been  discarded,  or  has  never  been  formally  documented  to 
begin  with. 

References 

AtMMndtf.  C .  MmuMiltwSvnhMrtBlFiiim  pp.  16-45 
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Patterns:  A  System  for  Achieving  Form/Context  Fit 


Patterns:  contaxt-*conflicting  forces->configuration 

ttfbiMoJvmd  &<>**  characteristics  of 
tfm  problem  which  an 
known,  ana  known  to 

bam  conflict  an  arrangement  of  pans, 

or  “form  which  nsohms 
the  conflict 


How  doas  this  apply  to  Software  Architecture ? 


r 


Gamma:  Handbook  of 
00  micro  architectures 


. nuil  l  lMi  ‘M  maUtM  I  Util  » 

f  rimmi  an  kivvvbnq  inRiugn  $ 
ooitrvpon 


h*U  to  pubHc  critique 
Thar*  an  nUMy  taw  pattens 


Lana:  Domain-specific 
design  rules 


TT 


Patterns:  A  System  for  Achieving  Form/Context  Fit 

It  should  not  be  aupiWng  that "patterne*  should  be  an  bnportant  concept  In  architeciure,  m  to*  la  an  etamemary  prerequisite 
for  turning,  ooddytng  knowledge  and,  ultimately,  win.  In  tie  architectural  him,  at  leaet  from  Alexander's  point  of  view, 
•  pattern  te  a  configuration  el  tend  which  faring  correcting  tones  Into  equMMum.  TNe  nation  of  pattern  crop*  up  repeatadty 
in  ttw  study  of  software  architecture: 

Gamma,  eL  al.,  hava  identified  laeuning  panarm  in  object-oriented  systems,  which  ha  rotors  to  aa  “micro*  art  hkec  lures. 
These  are  design  abatrecttona,  not  coda,  which  are  used  during  object-oriented  design,  to  tulMspecUr  needs  wUNnapsellic 
contaxti. 

Lane  aleo  searched  tor  what  amount  to  “panama.' or,  what  he  referred  to  as  design  rules  wfthin  a  design  speca  *  -  idea 
waa  to  uncover  *dstign  ruiaa*  which  eqarsss  structural  solutions  (i.a.,  implementation  daciaiona)  to  intoradiona  rr-  -  ao- 
tionaUpsrformanos  dimensions  (a.g.,  reapooaa  lima  va.  (PC  means)  Thaaa  design  rules  are,  in  effect,  pattama. 

Finally,  Shaw  and  Qarian  hava  uncovered  daaign  Idioms  which  hava  become  widely  uaad.  WMa  thaaa  Idiome  may  be  re¬ 
lated  to  atyta  (and  may  be  etyte),  whan  the  tdtorne  are  compoaad  they  begin  to  lock  more  Bca  pa  He  me. 

What  ia  significant  in  ail  ot  thia  ia  the  aaarch  tor  and  documentation  ot  budding  block  abatractiom,  or  daaign  alamante,  tttat 
work  in  practice. 

Gamma.  E..  Hatn,  A.  Johnson,  A.  VtoaUss.  A.  Daaign  Panama  •AOstraetton  and  Reuse  or  Ctyact  Oriented  Dealgtr-unpiSifohed  paper.  Corpora 

Eitcti  Gamma  a  TaHgsm,  me..  10725  N.  Oe  Ante  Bird.  Cupartmo.  CA  S50U-2000 

Goad  P.. 'Otifsct-Ortersso  Panama,*  Ccmmirtcattcnaot  me  ACM,  Vot  35.  No.  a.  SeptemOer  1*2. 

Alexander.  C.  Th«  jQaalsu  wav  rv  BuUdllB  Oxford  LWvaraxy  Praaa,  ISBN  0-ia-502402-S 

David  Qartan.  Shaw.  M..  *An  Introduction  to  Software  Archteewre.’  to  KXXtf  m  AcMances  m  Software  Engineering  and  Knowledge  Engineering. 
Vol  1  . 1993.  World  Soemite  Pubishing  Company 

Lana.  T.  G  .  StuOrina  Software  Arehneauree  tftrouoh  Desinn  Snores  and  Runs  CMU/SEi-90 -TR-18.  CMU.  PRBOurgh.  PA. 
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Architectural  Style 


Style  refers  to  a  quality  of  a  solution  which  brings 
all  of  the  design  elements  in  an  ensemble  into 
a  coherent  whole , 


Style  =  Design  Elements  +  Organizing  Principles 


some  stylos  hurt  j 
names: 


gothic 

post-modern 

prairie 


■ 

astound  In  patterns:  i 

entrance  ways 
transitions  j 

windows  j 

columns 

possibility  for  pre-fabrication  1 

I 


frequently  dependent  upon 
properties  of  element  materials 

stone  -*  vaulted  arches 
steel/glass  -*  vertical,  open 
sparse  wood-* light,  simple 

Aesthetics  and  social  factors,  to* 


How  does  this  apply  to  software  architecture? 

•  Can  software  architecture  be  expressed  with  a  small,  standard  set  of 
design  elements?  Are  the  design  elements  peculiar  to  a  style? 

•  Can  a  software  architecture  have  a  ubiquitous  style? 
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Architectural  Style 

There  is  a  higher-level  organizing  principle  than  patterns  and  pattern  languages  called  architectural  style 
(although  avid  followers  of  Alexander  might  claim  that  pattern  languages  embody  this  organizing  principle, 
and  that  the  only  “style"  that  matters  is  “patterns  that  live"). 

Some  of  the  styles  we  refer  to  are  known  even  to  novices  to  architecture:  the  Gothic  style,  the  Post-Modern 
style,  the  American  Prairie  style,  etc.  What  constitutes  a  style  is  a  combination  of  design  elements  and  the 
manner  in  which  the  elements  are  related  to  each  other.  Some  of  the  factors  in  selecting  organizing  prin¬ 
ciples  are  effected  by  the  materials  present  in  the  design  elements.  For  example,  the  use  oi  stone  or  ma¬ 
sonry  leads  to  a  very  different  organizational  approach  to  relating,  say,  an  entrance  way  to  a  large  room, 
then  will  be  the  case  if  steel  or  wood  are  used. 

What  makes  a  style  a  style,  of  course,  is  that  it  represents  a  coherence  among  the  design  elements— this 
is  what  is  meant  by  organizing  principles.  That  is,  we  would  not  expect  to  see  roman  columns  in  front  of 
an  American  Prairie  home  which  uses  reflective  glass  windows  in  steel  frames. 

This  "definition’  of  style  leads  to  a  different  applicability  of  style  to  software  architectures  than  usually  con¬ 
sidered.  That  is,  style  in  software  architectures  would  relate  more  to  the  set  of  design  elements  used,  and 
the  manner  in  which  those  elements  are  related— not  related  in  part,  but  related  in  the  entire  ensemble. 
That  is,  software  architectural  style— to  be  style— must  describe  systemwide  organizational  principles.  Ex¬ 
amples  will  be  found  in  structural  modeling  and  Genesis. 
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Roadmap  for  this  Session 


Architecture:  Muffl-Dteclpllnarv  Overview 


Manufacture  Perspective 


Engineering  Perspective 


Architecture  Perspective 


•  production  discipline  and  automation 

•  Interchangeable  parts  and  assemblies 

•  prooaaa  control 

•  engineering  dtedpHne 

•  codified  knowledge  In  enrtneering  mod*  Is 

•  predtoteble  results  through  compoaltlon 

•  daaign  dtedplne 

•  form  and  context:  bounda  on  crMtivtty 

•  daaign  pattams  and  “style" 


Software  Architecture:  Overview 


ar  Scientific  Foundation 


•  identification,  classification,  description 

•  abstraction  and  analysis 


Engineering  Application 


•  abstract  and  concrete  models 

•  anglnaartng  and  production  techniques 


Considerations  in  Practice 


•  strategic/business  considerations 

a  policy  ItWft 

•  economic  Issues 


l 
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Perry  and  Wolf:  Context  of  Architecture 


Requirements 


Architecture 


Design 


Implementation 


•  system  characteristics 

•  user  needs 


•  design  elements  / 

•  interactions  among  elements  \ 

•  constraints  on  etementsAntaraeOons  \ 


•  description  and 

$ 

ot  style 

•  capture  lorn  and 
contest 


•  modularisation  and  detailed  Interfaces 

•  algorithms  and  data  types 


•  representation  and  encoding 
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Perry  and  Wolf:  Context  of  Architecture 

A  good  place  to  start  in  understanding  software  architecture  is  the  Foundations  paper  by  Dewayne  Perry 
and  A.  Wolf.  We  start  here  because  Peny  and  WoH  make  the  strongest  case  for  building  on  the  analogy 
of  classical  architecture  in  the  study  of  software  architecture,  particularly  as  concerned  with  the  notion  ol 
architectural  style. 

The  chart  illustrates  a  starting  point  in  the  discussions:  that  software  architectue  is  both  a  discipline  of  de¬ 
sign.  and  also  a  representation  of  design.  Specifically,  software  architecture  as  ilustrated  is  a  kind  of  high- 
level  design.  The  key  points  of  the  Perry/Woll  paper  are: 

•  architecture  is  a  discipline  with  standards,  codified  styles  and  education 

•  architecture  captures  important  high-level  concepts  in  a  system  which  must  be  preserved, 
and  which  make  global  assertions  about  the  system 

•  multipie  views  are  needed  to  express  an  architecture 

•  strong  analogies  are  made  between  the  notions  of  "style"  in  software  and  classical 
architecture 
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Perry  and  Wolf:  Elements ,  Form,  Rationale  and  Views 
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Perry  and  Wolf:  Elements,  Form,  Rationale  and  Views 

An  architecture  is  comprised  of  elements,  torm  and  rationale. 


Elements  form  the  basis  for  various  views:  process,  data  and  connectors.  The  figures  illustrate  two  sepa¬ 
rate  views  for  a  canonical  compiler  the  connector  view  is  implicit  '$  procedural/jpammeter  connector  view). 
Alternative  process  and  data  views  emerge  if  alternative  connector  strategies  are  determined 

The  notion  of  torm  parallels  that  of  the  discussion  earlier  in  the  classical  architecture  discipline.  Form  is 
concerned  with  constraints  on  the  use  and  arrangement  of  various  design  elements.  We  should  note  that 
Perry  and  Wolf  admit  to  some  ambiguity  between  “style'  and  “design”  decisions,  indicating  that  there  is 
some  gray  area  between  architecture  style,  architecture  and  design. 

Note  that  rationale  is  also  included.  This  relates  strongly  to  the  notion  of  architecture  as  a  complete  en¬ 
semble  of  context  and  form.  In  this  case,  additional  rationale  inks  are  made  between  the  torm  and  its  more 
detailed  reaizations  in  design. 
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Perry  and  Wolf:  Constraints  on  and  Nature  of  Style 
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Perry  and  Wolf:  Constraints  on  and  Nature  of  Style 

One  of  the  most  important  points  of  the  Peny/WoH  concept  concerns  the  relationships  between  architec¬ 
ture  style  and  materials  and  engineering  cSsdpiines. 

In  the  context  of  software  architecture,  toe  Mowing  analogy  can  be  made: 

•  style  and  materials:  the  selection  of  a  style  must  take  into  account  toe  kinds  of  components 
which  may  be  reused  or  fabricated,  toe  languages  used  to  build  and  combine  components, 
properties  ol  the  execution  environment  (network  speed,  processor  speed,  etc.). 

•  style  and  engineering  principles:  different  computer  science  disciplines  are  involved  in  the 
use  of  different  styles.  A  distributed  and  concurrent  style  will  involve  different  principles  than 
a  simpler  caB/retum  style. 

These  considerations  form  part  of  toe  context  tor  toe  form  to  be  pnoduoed. 
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increasing  abstraction 


Shaw  and  Garlan:  Context  of  Architecture 
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Shaw  and  Garian:  Context  of  Architecture 


Shaw  and  Garian  are  closer  to  toe  practice  of  architecture  in  their  work  than  the  Peny  and  Wplt  paper. 
Although  Shaw  and  Garian  shares  toe  view  of  architecture  as  high-level  design,  they  also  consider  the 
study  of  architectures  to  be  a  natural  next-step  in  toe  evolution  of  computer  science  abstractions. 

Again,  using  toe  metaphor  of  a  pattern,  we  can  see  a  certain  historical  trend  towards  toe  study  of  higher- 
level  abstractions  for  larger-scale  systems. 
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Shaw  and  Garland:  Taxonomy  of  Styles 
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Shaw  and  Garland:  Taxonomy  of  Styles 

Uke  Perry  and  Well,  Shaw  and  Garlan  define  architecture  In  terms  of  constituent  design  elements  and  con¬ 
straints  on  the  elements.  The  exact  definition  is  a  bit  diflerent. 

In  this  case,  the  elements  ere  components  and  connectors,  described  in  some  kSom- specific  manner.  The 
particular  idioms  are  represented  as  topologies  of  the  component/dnonector  vocabulary,  along  with  con¬ 
straints  on  how  the  topologies  can  be  arranged. 

Shaw  and  Garlan  have  classified  a  number  of  idioms,  and  describe  their  general  properties,  etc.  using  a 
consistent  descriptive  framework.  This  taxonomy  has  emerged  from  case  studies  of  actual  systems.  It  is 
the  foundation  for  courses  taught  at  CMU  on  the  topic  of  architecture  and  software  design,  it  has  also  been 
widely  published  and  distributed  through  technical  literature  and  tutorials  provided  by  Garlan  and  Shaw. 
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Shaw  and  Garland:  Heterogeneous  Styles 

It  is  interesting  to  note  hat  Garten  and  Shew  have  observed  that  systems  do  not  usually  consist  (X  a  single, 
consistent  idiom  that  is  used  across  on  entire  system.  For  example,  they  provide  exan^jles  in  case  stud»6 
of  systems  which,  at  one  level  of  abstraction  present  one  idiom,  white  a  single  component  within  this  kfcom 
is  realized  through  an  entirely  different  idiom. 

It  is  not  dear  whether  ttua  indicates  the  limits  ot  the  analogy  made  with  ffadffional  architecture— concerning 
the  notion  of  style  as  a  consistent,  global  property  of  a  system.  It  may  be  that  software  systems  are  inher¬ 
ently  -recursive"  in  design  through  many  levels  of  abstraction,  in  which  case  "style"  could  be  constrained 
to  any  one  aspect  or  view  of  a  system  design. 
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Shaw  and  Garland:  Styles  as  Reference  Models 
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Shaw  and  Garland:  Styles  as  Reference  Models 

Another  interesting  aspect  of  this  work  to  the  use  of  styles  or  Idioms  as  a  way  of  examining  legacy  designs 
At  least  one  case  study  is  provided  which  Mustrates  how  e  system  can  be  viewed  from  multiple  idtoms.  and 
how  each  idtom  reveals  aome  characteristic  about  the  system  under  observation. 

The  example  ilustrated  is  a  natural  language  processing  system  viewed  through  the  interpreter  idtom  and 
the  blackboard  idiom. 

What  is  significant  and  worth  noting  i6  that  this  Mustrates  the  usefulness  of  architectural  abstractions  in  the 
analysis  and  understanding  o(  properties  o(  software  designs. 
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Gamma,  et.aL:  Handbook  of  Object-Oriented  Patterns 

Other  researchers  and  practitioners  have  adopted  a  similar  approach  to  Shaw  and  Gartan,  but  at  a  dftoient 
scats.  For  example,  this  chart  Uustrales  a  fragment  of  a  taxonomy  of  ‘mcro"  architectures  found  in  object 
oriented  systems.  The  term  micro  architecture  is  used  by  Gamma  (one  of  the  authors  of  the  handbook) 
because  the  scale  includes  a  configuration  of  objects  and  classes  which  would  be  combined  with  other 
micro-architectures  to  create  an  application.  In  contrast,  the  ktioms  of  Shaw  and  Gartan  “leer  larger 
grained. 

Note  that  it  is  within  the  00  community  that  the  largest  (tired  use  of  concepts  from  Christopher  Alexander 
are  found.  This  might  be  because  the  00  community  tends  to  be  more  avant  guard,  or  it  might  be  that  the 
arguments  made  by  Alexander— that  the  design  elements  of  architecture  must  be  closer  to  the  physical 
world— have  a  natural  setting  in  object-oriented  design,  which  espouses  a  similar  principle  of  abstraction 
forming. 


With  this  we  leave  the  science  and  philosophy  of  architecture  behind,  and  examine  some  of  the  engineer¬ 
ing  factors— technology  and  process. 
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Software  Architecture:  Overview 
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Some  Topics  In  Engineering  Application 


•  Architectural  Style  and  Formalized  Design  Elements 
-  Style  and  Engineering  Design 

•  Style  and  Automation 

•  Design-Process  Generated  Design  Elements 

•  Module  Interconnection  Formalisms 

•  Evaluation  of  Architectures 
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Some  Topics  in  Engineering  Application 

There  are  quite  a  variety  of  topics.  The  following  dtocussion  touches  on  only  a  lew  important  topics.  Notably 
absent  from  Ihe  discussion  are  discussions  on  the  relationships  between  architectural  styles  and  design 
methods,  impact  of  software  architectures  on  life-cycle  processes,  relationship  between  structural  versus 
behavioral  descriptions  in  architecture,  etc. 

The  topics  which  are  addressed  were  selected:  to  amplify  concepts  inkoduoed  in  the  earlier  discussions: 
to  introduce  some  technology  considerations  which  wil  be  relevant  in  later  discussions;  and  to  provide  ties 
wherever  possible  to  ongoing  software  engineering  efforts  (both  in  theory  and  practice). 
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Architecture  Style  and  the  Engineering  Design  Process 
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Architecture  Style  and  the  Engineering  Design  Process 

One  lustration  of  the  idea  of  consistent  ■style*  in  software  architectures  is  provided  by  the  OCU  model: 
Object.  Connect,  Update.  A  thumbnail  description  of  this  “style"  is  provided.  Essentially,  the  style  is  orga¬ 
nized  around  the  idea  of  subsystems,  subsystem  controHereandobjects.lt  is  an  austere  model  which  con- 
stitutes  a  style  because  it  has  a  few  primitive  design  elements,  and  rales  lor  combining  the  elements. 


The  Chart  is  meant  to  illustrate  how  an  architectural  style  can  be  used  within  the  context  of  an  engineering 
process.  First,  by  constraining  the  form  of  the  solution  so  tightly,  the  style  itself  can  serve  as  a  tool  for  help- 
ing  form  the  problem  space  during  the  problem  forming  process.  That  is,  the  style  provides  a  kind  of  vo¬ 
cabulary  for  discussing  the  problem  space.  Similarly,  once  formed,  the  problem  can  be  "set"  in  terms  of 
the  style  as  well. 


Perhaps  this  is  nothing  more  than  the  observation  made  by  object-oriented  designers  in  undertaking  a  kind 
of  object-oriented  analysis  phase  prior  to  design.  On  the  other  hand,  the  very  restrictive  style,  if  sufficient 
for  the  problem  spaoe,  can  be  said  to  aDow  the  software/system  designer  to  focus  creative  energies  where 
they  are  needed  most,  rattier  than  on  re-inventing  structural  or  coordination  models  tor  each  new  problem. 

The  OCU  style  was  used  in  practice  as  the  basis  for  a  flight  simulator. 
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Architectural  Style  and  CASE  Tooling 
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Architectural  Style  and  CASE  Tooling 

The  previous  chart  bustrated  the  rale  that  architecture  style  can  play  in  the  engineering  process.  It  is  also 
the  case  tost  defining  an  architecture  style— identifying  design  etements  and  rules  tor  combining  these  el- 
emente— i provides  opportunities  for  automation.  Only  two  of  many  pocsMe  instances  are  Uuetrated  here: 
UNAS/SALE,  a  commercial  product  marketed  by  TRW,  end  SARA,  a  wed-known  research  system. 


In  each  case,  these  systems  are  constructed  on  a  foundation  of  a  tow  primitive  elements,  and  larger  sys- 
terns  can  be  specified  and  executed.  Other  tools  include  the  miao-Rapide  language/system  being  devel¬ 
oped  as  part  of  the  ARPA/ProloTech  protect  and  various  other  tools  for  specifying  properties  of 
architectures. 


Incidentally,  although  ttrere  are  many  design  tools  which  provide  primitives  fa  describing  characteristics 
of  system  designs,  the  term  “architecture  description  lang<jage*  tends  to  apply  to  only  those  notations  that 
describe  components  and  component  interactions  (further  evidence  of  the  appropriateness  of  the  Shaw 
and  Garian  perspective  on  software  architectures). 
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Batory:  Design-Method  — >  Architecture  Style 


Batory:  Design-Method  — >  Architecture  Style 

Architecture-level  automation  does  not  always  appear  to  depend  upon  pre-definition  of  a  small  number  of 
design  elements.  Batory  has  demonstrated  application-specific  ge neratortf composition  based  upon  soft¬ 
ware  architectures  in  non-trivia)  application  domains. 

In  this  case,  the  architectural  style  is  said  to  be  layered,  but  there  are  no  further  design  primitives  lor  de¬ 
scribing  these  layers  beyond  those  reflected  in  the  interlaces  to  components  which  result  from  a  domain 
engineering/domain  design  process.  That  is,  rather  than  defining  primitive  design  elements  tor  describing 
software  architectural  abstractions,  Batory  et.  al.  have  defined  a  design  process  for  producing  components 
which  have  certain,  constrained  properties.  It  is  these  properties  which  alow  automation  and  generation 
of  appfications  from  the  design/architecture. 

In  this  method,  components  are  aggregates  of  classes  and  objects  which  implement  what  amounts  to  a 
"subsystem*  with  each  component  representing  a  specific  layer  in  a  layered  architecture.  The  type  model 
implemented  by  these  higher-level  (component)  abstractions  slows  higher-levels  of  tie  design  to  be  pa¬ 
rameterized  by  lower  levels. 
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Architecture  and  Module  Interconnection  Formalisms 


One  form  of  module  interconnection 
formalism  addresses  the  need  to 
separate  coordination  from  function 

The  need  is  especially  strong  in 
reusing  components  where  systems 
will  vary  by  distribution  and  heterogeneous 
platforms 

Examples:  Polylith,  Linda 


Another  form  of  module  interconnection 
formalism  addresses  higher-level 
semantics  of  component  composition 

Examples:  LILEANNA,  P++ 
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Architecture  and  Module  Interconnection  Formalisms 


S  moat  cun  an  important  consideration  in  software  architectures  •  haw  concrete  software  component*  can  Hf  A  quee- 
lion  oonceming  the  relalwnehipe  between  software  components  and  architecture*  arises  where  feature  binding  time  it  eorv 
oomad.  Eapedely  whore  reuse  it  cone* mod,  architecture  wm  implies  some  flexfciiity  in  selecting  application  leakxee.  If 
components  prematurely  ombad  cortain  features  the  probability  of  rauaing  thaaa  components  it  decreased. 

Ona  kequenty-erxxxjmered  problem  ia  that  ooda,  aapaciaily  tor  distributed  ayalama,  embeds  coordination  logic  which  ia  ar¬ 
cana  and  makes  tha  coda  non-rauaabia.  Sinca  tha  "connections'  among  componanta  at  an  architecture  level  may  imply  co¬ 
ordination  medals,  it  would  ba  nioa  to  have  too  maana  of  separating  trees  coordination  mods  la  tom  tha  underlying 
components— that  is  one  purpose  for  MIFe. 

A  second  purpose  concerns  too  manipulation  of  softwara  componanta  aa  design  olamanta  in  that  own  right.  To  aama  aidant 
9ti»  is  already  poaeUe  with  object-oriented  languages  (allhoik)hBatoty  has  noted  eomelimrtatiana  along  these  inee.)  MIFe 

which  extend  tha  ancapaulalion/abataction  of  programming  language  mod  lias  to  aifiport  a  mot*  textile  composition  at 
daaign-lime  would  ba  nica.  Languages  such  aa  ULEANNA  and  P++  are  designed  with  thaaa  kinds  of  iseuaa  in  mind,  Md 
alow  tor  combining  modulaa,  adetng,  removing  and  httng  capabilities  of  modules,  parameterizing  modules  with  other  mod- 
ulaa,  and  so  on. 

David  Gelerator,  Carriaro,  N.,  'Coordination  Languages  and  their  Significance,-  Communications  of  the  ACM,  VoL  35  No.  2, 
1992. 

John  Callahan,  PurOto,  J.,  *A  Packaging  System  for  Heterogeneous  Execution  Environments,"  IEEE  Transactor's  on  Soft¬ 
ware  engineering,  Vol.  17  No.  6,  June  1991. 

VNek  Singhal,  Batory,  D.,  Pee:  A  Language  tor  Software  System  Qeneraiors,  Technical  Report  TR-93-16,  Department  of 
Computer  Serenes,  University  of  Texas  at  Austin,  1993. 


WB  Traci,  "Parameterized  Programming  in  ULEANNA*  urpifetiehed,  IBM  Federal  Systems  Company. 
QMG  'The  Common  Object  Request  Broker.  Architecture  and  Specification"  1992 
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SEhSAAM— Software  Architecture  Analysis  Method 


SEhSAAM— Software  Architecture  Analysis  Method 

Of  practical  concern  k  whether  and  hour  we  can  go  about  evaluating  toe  qualities  o*  software  architectures.  Them  am  ape- 
dfkt  "metrics-  reliable  tar  UMUing  quality  toctara  of  aourea  coda— modularity,  oomptaxlty,  ate.,  and  partiapa  than  am 
maaauraa  that  could  apply  to  behavioral  chamctariatica  of  a  ayatam— data  throughput,  maan  raaponaa  lima,  maan-tima  to 
fatiure,  ate.  But,  practicaly  speaking,  how  doae  one  evaluate  the  miativo>»dnees‘otafchifaclume? 

Tha  Software  Architecture  Analysis  Method  haa  some  taaturaa  worthy  of  note.  Fxst,  thara  ia  an  inversion  of  lha  Qarian/Shaw 
concapt  of  axamining  a  daaign  Irom  tha  parapaciiva  of  mUtipie  atytaa.  In  SAAM  multiple  deeigna  are  examined  from  tie  per¬ 
spective  of  a  a  ingle  mtamnea  modal.  Tha  rafamnea  modal  la  a  canonical  functional  partitioning  of  applicatian  functions— it 
looks  Nee  a  high- level  domain- specific  daaign. 

Tha  second  interesting  feature  ia  lha  use  of  an  architecture  desorption  language  (ADL).  In  conjunction  with  tha  mtamnea 
modal,  individual  "unique*  architectures  can  be  “profiled,-  am  in  a  fleet  m-cast  in  terms  of  tha  mtamnea  modal  and  tha  ADL 
In  thie  way  disparate,  unique  designs  are  “normelaeff  to  a  common  linguistic  framework.  Note  that  the  ADC  used  ia  tnruearl 
on  structural  aspects  ol  tha  daaign;  apecffic  behavioral  description  ia  imitad  to  tie  idea  ot  tontrol  tow*  and  •process.*  Tha 
design  ol  tie  ADL  may  have  bean  influenced  by  tha  apptcation  domain:  tha  differentiation  ot  'active*  from  ‘passive-  repos¬ 
itory-  seams  to  indwata  toe  influence  of  one  or  mom  representative  archHacfoma  within  tha  domain  being  skated. 

Tha  third  intern  sting  feature  is  that  quality  factors  am  selected,  along  with  ^ecitic  scenarios  which  exercise  tie  qualty  lac- 
tom.  Note  that  tha  quality  factors  am  teemed  on  eo-caled  rton- functional  system  chamctariatica:  in  tha  paper  titasa  factom 
were  focused  on  various  dimensions  of  ayatam  adaptability.  Kaiman,  at.  ai.  deem  toe  quality  factors  to  be  relevant  to  a  spe¬ 
cific  organizational  context,  not  necessarily  to  the  application  domain.  Other  non-functional  quality  factors  may  be  of  use  in 
different  contexts. 

Kazman,  R. ,  Bats,  L ,  Aboard,  G  ,  Webb,  M„  Analyzing  Properties  of  User  Interface  Software  to  be  released  as  a  Technical 
Report,  Software  Engineering  Institute,  Carnegie  Mellon  Univarsity,  Pittsburgh  PA. 
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SEI:  Information  Architecture  and  Non-Functional  Analysis 


Information  Architecture 
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non-tunctfonal 
quality  faaturas 
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at  tha  la  ghost 
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Layer  2:  Derived 
Architecture 


/  Layers:  Design 
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-  maintainability 

-  evolve-abiHty 

'Dependability 

-availability 
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•etc. 

Scenario*; 
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SEI:  Information  Architecture  and  Non-Functional  Analysis 

A  draft  paper  by  Salasin  of  tre  SEI  on  analysis  of  non-functional  characteristics  of  architectures  lor  the  Bal- 
Bstic  Missile  Defense  Organization  (BMDO)  Battle  Manage  ment/Command  Control  Communications 
(BM/C3)  System  discusses  process  and  representation  issues  ol  ensuring  satis  tact  ion  ol  nonfunctional  qual¬ 
ity  features.  Instead  of  post-mortem  evaluation  of  critical  quality  factors  the  approach  described  builds  -satis¬ 
faction*  into  the  architecture  refinement  process  and  architecture  representation.  Some  notable  points: 

1 )  The  -information  architecture*  reflects  a  complete  design  ensemble  (context/form,  here  expressed  as  prob¬ 
lem  space/solution  space).  The  "mission  architecture,"  for  example,  models  the  operational  requirements  (the 
"shain  as  well  as  the  concepts  of  operation. 

2)  Non-functional  qualities: 


•  are  made  explicit  in  the  tornr  of  mdcatorer 

•  are  tied  to  objects  In  the  information  architecture; 

•  are  used  to  define  scenarios  tor  evaluatioiVverification  purposes  (similar  to  SAAM); 

•  have  metrics  associated  for  quantitative  evaluation  of  rKficators(Le..dkf  the  commitment  satisfy 
the  obligation?) 

3)  The  process  for  managing  the  non-functionei  requirements  is  step-wise,  and  can  be  integrated  with  existing 
design  reviews. 

References 

John  Salasin,  Waugh,  D.,  "An  Approach  to  Analyzing  Non-Functional  Aspects  During  System  Definition,* 
Draft  Technics!  Paper,  in  Proceedings  of  Are  ARPA/DSSA  VII  Workshop. 
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Roadmap  for  this  Session 


Architecture:  Muttl-Disciplinary  Overview 


Manufacture  Perspective 
Engineering  Perspective 
Architecture  Perspective 
Software  Architecture:  Overview 


•  production  dtedpllne  and  automation 

•  interchangeable  parts  and  assemblies 

•  process  control 

•  engineering  eMsdpine 

•  codHled  knowledge  In  engineering  models 

•  predetabie  results  through  composition 

•  dftflti  dtodpBnt 

•  torn  and  context:  bounds  on  creativity 

•  design  patterns  and  “style” 


Scientific  Foundation 


•  Identification,  dassltlcatlon,  description 

•  abstraction  and  analysis 


Engineering  Application 


•  abstract  and  concrete  models 

•  engineering  and  production  techniques 


as*  Considerations  in  Practice 


•  strategic/business  considerations 

•  policy  Issues 

•  economic  Issues 
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Practical  Considerations 


•  System  v.  software  engineering  and  binding  time  of  design  decisions... 

•  Procuring  architectures  without  over-  or  under-constraining  the  form 
(reference  models,  tools  and  representation  standards).- 

•  How  to  allow  technology  progression  and  introduction  of  new,  more  op¬ 
timal  solutions  (architecture  life  cycle)-. 

•  Re-engineering  and  architectures— migration  and  interoperation  of  lega¬ 
cy  systems-. 

•  Ownership  and  rights-. 

•  Domain  engineering  and  domain  management- 


AND...  Much  Much  More.  The  Workshop  is  intended  to  identify  issues  from 
the  perspectives  of  engineering  practitioners,  program  managers,  policy 
makers  and  other  stakeholders. 


This  page  intentionally  left  blank. 
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Summary  of  " Senses  of  Architecture” 

•  There  ere  a  diversity  of  perspectives  on  what  is  “important"  in  the  study  of 
software  architecture 


•  There  are  interesting  and  useful  analogies  in  the  areas  of  manufacturing, 
classical  engineering  and  classical  architecture 

•  The  computer  science  and  software  engineering  foundations  are  not  mature 

•  There  we  a  range  of  practical  considerations  for  the  adoption  of  software  ar¬ 
chitecture  in  the  DoD 


This  page  intentionally  left  blank. 
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Towards  a  Science  of  Architecture 
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Trends  in  Architecture  for  Reuse 

Architecture-Based  Reuse 
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Two  Key  Questions  In  the  Search  for  Architecture 


Architecture:  High-Level  Design 


Requirements 


Architecture:  Design  Discipline 


Design 

Implementation 


Product  Perspective 


Process  Perspective 


If  this  Is  valid,  then  the  question:  If  this  Is  valid,  then  the  question: 
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Two  Key  Questions  in  the  Search  for  Architecture 

Session  two  ol  the  seminar  covered  many  different  perspectives  on  the  topic  architecture.  We  are  in  a  po¬ 
sition  of  hypothesizing  about  the  structure  of  the  conceptual  category  ’architecture  *  This  is  not  the  same 
as  providing  an  axiomatic  definition.  Instead,  we  will  adopt  a  phenomenological  approach:  based  on  the 
concepts  we  have  highlighted  earlier,  can  we  identify  what  characteristics  we  might  observe  of  software 
architectures? 

Before  we  do  so.  two  premises  need  to  be  established,  and  two  derivative  questions  proposed,  to  justify  a 
phenomenological  approach.  Note  that  only  one  of  the  premises  need  to  be  true,  although  both  could  be 
true,  for  a  phenomenological  approach  to  be  reasonable  (although  our  notions  of  architecture  phenomena 
might  still  be  invalid). 

1.  Hit  is  valid  that  software  architecture  is  ahigh  level  design,  then  is  it  true  that  all  designs  have  an  archi¬ 
tecture?  We  believe  that  not  at  designs  are  ‘architected"  designs,  in  the  same  way  that  not  al  programs 
are  structured  programs. 

2.  If  it  is  valid  that  architecture  is  a  cfisdpline  of  design,  then  is  it  true  that  the  forms  produced  by  the  process 
w*  be  different  from  the  forms  produced  by  a  non-architectural  design  discipline?  We  believe  that  not  al 
design  processes  are  based  on  principles  of  architecture,  and  that,  in  general,  current  design  processes 
do  not  produce  architected  designs. 

If  you  accept  the  premises,  the  questions  and  our  answers,  then  it  is  reasonable  to  ask  whether,  in  theory, 
one  could  observe  differences  between  architected  and  non -architected  forms  (i.e.,  designs).  If  there  are 
no  observable  forms,  then  why  study  software  architecture?  It  there  are  differences,  what  are  they? 

The  following  seven  characteristics  of  software  architecture  need  not  be  considered  as  a  rigid  statement. 
It  is  not  dear  that  ail  elements  need  to  be  present  On  the  same  way  that  a  three-legged  elephant  is  still  an 
elephant).  And,  naturally,  there  may  be  characteristics  which  we  have  not  induded.  144 


How  do  ^architected*  designs  differ 
from  non-archftocted  designs? 
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Seven  Characteristics  of  Software  Architecture 


1.  Identifiable 
Dtaign  Etemante 


•  relatively  few  elements 

•  structural  and  behavioral 

•  component/connector  level 

•  function  v.  form  v.  coordination 


2.  Patterns 


•  configurations  of  design 
elements 

•  repeated  organizing  strategies 

•  scale  through  repetition 


3.  Named  Patterns 


•  standard  configurations 

•  documented  characteristics 

•  descriptive  and  prescriptive 


4.  Style 


•  coherency  among  patterns 

•  system-wide  pattern 

•  see  the  whole  from  a  part 
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Seven  Characteristics  of  Software  Architecture 

NOTE:  W*  do  not  cum  Hal  al  ctmcMMies  mat  Im  praMM,  or  IM  M*  raprawni  ■  compraliMalw  mi  al  duncMiMla.  W*  b»- 
torn  «0efS»Mate>mnit  may  to*  sbMnaif  in  (rcNtKtodiMgna 

1 .  Irtantilinhifl  Design  Elamanni  As  we  noted  earlier,  one  characteristic  Of  architectures  is  that  they  may 
be  represented  in  terms  of  so-called  architecture  description  languages  (ADLs).  There  are  various  com¬ 
puter-aided  software  engineering  (CASE)  tools  which  claim  to  be  'architecture*  tools,  and  they  have  cod¬ 
ified  abstractions,  rules  lor  composing  specifications  from  these  abstractions,  and  environments  tor 
simulating/executing/evaluating  these  specifications.  The  SEI  Object/Connect/Update  (OCU)  "style*  also 
has  identifiable  design  elements:  objects,  controllers,  import/export  areas,  etc.  Note  that  architecture  de¬ 
sign  elements  should  pertain  to  the  structure  and  behavior  of  systems  at  the  component/connector  level 
of  abstraction.  It  should  be  possible  to  separate  application  functionality  from  structure,  and  structure  from 
coordination  among  structural  elements. 

2.  Patterns.  Patterns  may  be  reflected  in  the  types  of  design  elements  and  composition  rules,  and  in  spe¬ 
cific  configurations  of  design  elements.  However,  patterns  are  not  dependent  upon  specialized,  architec¬ 
ture-level  design  elements— they  can  be  reflected  in  the  properties  of  implementation  elements  such  as 
code  components,  modules.  For  example,  type  properties  presented  by  component  interlaces  which  are 
generated  by  a  design  method  also  represent  architectural  patterns. 

3.  Named  Patterns  Patterns  should  have  sufficiently  regular  and  predictable  form  to  be  recognized  and 
documented.  The  features  of  the  pattern,  its  strengths  and  weaknesses,  and  the  contexts  for  the  use  of 
the  pattern,  should  be  apparent  in  the  pattern  definition.  The  patterns  should  be  descriptive.  i.e.,  support 
understanding,  and  prescriptive,  i.e.,  support  reasoning. 

4.  Style.  Style  refers  to  a  system-wide  pattern,  or  the  application  of  principles  which  bring  about  a  state  of 

coherency  among  the  patterns  used  in  a  design.  Styles  should  also  be  name-able,  and  permit  description 
and  prescription  analogously  to  named  patterns,  but  at  a  systems  level.  t«s 


Seven  Characteristics  of  Software  Architecture  (Cont.) 


•  problem  and  solution  space 

•  alternatives  and  rationale 

•  reason  about  context  from 
form 


5.  Complete  Context/Form 
Ensemble 


6.  Tied  to  Physics 


•  general  laws:  mathematics 

•  application-specific  physics 

•  material  constraints:  hardware 


7.  Adaptable  Form 


•  form  optimized  for  anticipated 
changes 

•  resilience  to  drift  and  erosion 
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Seven  Characteristics  of  Software  Architecture  (Cont.) 

5  Complete  Context/Form  Ensemble.  As  noted  earlier  a  design  problem  consists  of  a  context  and  a  farm 
The  idea  of  linking  the  form  to  context  appears  repealed— in  Petty  and  Woifs  definition,  in  Salasins  infor¬ 
mation  architecture,  and  as  will  be  seen  where-ever  design-level  reuse  is  anticipated.  We  can  think  of  the 
following  two  characteristics  as  teveafing  different  aspects  of  a  design  ensemble. 

6.  Tied  to  Physics.  In  the  engineering  cSsdpfine  the  laws  of  nature  define  the  boundaries  of  problems  and 
solutions.  There  are  equivalent  laws  ol  nature  in  the  problems  and  solutions  of  software  systems.  As  virtual 
machines,  software  depends  upon  the  mathematics  of  computation— it  is  hoped  that  as  the  discipline  of 
design  and  architecture  mature,  more  formal,  mathematical  reasoning  about  designs  wBI  become  com¬ 
monplace  (temporal  logics,  type  logics,  calculus  of  communicating  systems,  etc.).  Designs  need  also  be 
tied  fo  the  practice  of  engineering  within  an  application  area — oesigns  tor  control  systems  may  look  differ¬ 
ent  from  designs  for  information  management  systems.  Fmaly,  there  are  materials  physics— virtual  ma¬ 
chines  are  implemented  on  real  machines  which  define  physical  constraints  on  software  solutions.  All  of 
these  factors  represent  part  of  toe  "context"  tor  a  design. 

7.  Adaptable  Form.  This  may  be  the  most  important  characteristic:  it  should  be  possible  to  reason  about 
the  adaptability  of  the  design  from  its  form.  As  already  observed,  the  context  for  software  is  constantly 
changing,  and  changing  at  an  increasingly  fast  pace.  The  missions  for  software  are  booming  more  com¬ 
plex,  and  the  capabilities  of  hardware  are  pushing  (or  are  being  hindered  by)  software  capacities. 
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A  Note  on  Concept  and  Terminology 


A  Note  on  Concept  and  Terminology 

The  myriad  uses  of  the  noun  'architecture*  g  sometimes  contusing— overuse  may  result  in  a  degenerate 
vulgarization  of  important  concepts.  It  should  be  possible  to  more  deanty  differentiate  the  concepts  o<  Tie 
design"  from  "the  architecture* 


One  possible  partitioning  strategy  is  illustrated  on  the  chart.  In  it  we  establish  the  notion  that  architecture 
is  about  producing  designs.  There  are  (at  least)  two  disciplines  involved:  one  involving  the  structuring  ot 
software,  the  other  involving  the  appication  of  engineering  "know  how”  in  problem  solving.  The  structuring 
of  software  involves  computer  science  and  software  architecture ,  the  engineering  ‘Vnow  how"  involves  en¬ 
gineering  problem-solving  approaches,  disciplines  and  domain/application  expertise. 


With  this  viewpoint  the  question  *what  is  your  architecture*  is  more  dearly  directed  towards  application- 
independent  structuring  and  styling  issues,  while  "what  is  your  design’ is  more  deariy  directed  towards  the 
specified  solution. 
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Architecture  “Defined” 


ht  Towards  a  Science  of  Architecture  _ _ _ _ 


•  phenomenology 

•  externally  visible  qualities  of 
architecture:  a  hypothesis 

•  Idnds  of  architectures 


Trends  in  Architecture  for  Reuse 

Architecture-Based  Reuse 
Systems 


•  object-oriented  architectures 

♦*'  .  event-based  architectures 

•  object-oriented/event  hybrids 

•  overview  of  concepts 

.  anstogy  with  configuration 
management 
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Toward  a  Science  of  Software  Architecture 

•  What  kinds  of  software  architectures  exist? 

•  What  kinds  of  software  architecture  best  support  re¬ 
use? 


Toward  a  Science  of  Software  Architecture 


These  two  questions  are  important  tor  this  seminar.  Hie  tret  pert  of  this  session  will  attempt  to  answer 
these  questions.  At  this  point  it  is  appropriate  to  survey  some  of  the  architecture  styles  that  were  identified 
by  Garlan  and  Shaw.  The  graphic  shows  that  getting  to  a  theory  of  software  architecture  is  an  upstream 
paddle. 


What  Kinds  of  Software  Architectures  Exist? 


What  Kinds  of  Software  Architectures  Exist? 


Academic  researchers  are  currently  studying  and  classifying  architectures  (similar  to  the  way  a  biologist 
would  study  species  of  plants  or  animals).  Hopefully  the  wil  lead  to  the  identification  of  common  styles 
(idioms)  and  system  patterns.  The  long  term  goal  is  to  develop  guidelines  tor  applying  these  styles  and 
patterns  in  new/re-engineered  systems.  The  main  styles  and  patterns  that  have  been  identified  so  far  are 
explained  briefly  below. 

Data  Flow  style: 

•  Batch  Sequential  •  each  step  runs  to  completion 

•  Pipes  and  Filers  -  linked  stream  transformers 

Can  and  Return  style: 

•  Main  program  and  subroutines  •  traditional  functional  decomposition 

•  Hierarchical  layers  •  well  defined  interlaces  and  information  hiding  (e.g.  kernels,  shells) 

•  Object-oriented  systems  -  abstract  data  types  with  inheritance 


Reference:  Gartan,  Shaw  •  "An  Introduction  to  Software  Architecture’  to  appear  in  Advances  in  Software 
Eng.  and  Knowledge  Eng.,  vol.l  1993 
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What  kinds  of  Software  Architectures  Exist? 


Data-centered  systems 


What  Kinds  of  Software  Architectures  Exist? 


Independent  Components  style: 

•  Communicating  processes  •  asynchronous  message  passing 

•  Event  systems  -  implicit  invocation 


Virtual  Machines  style: 

•  Interpreters  -  input  driven  state  machine 

•  Rule-based  systems  •  rule  based  interpreter 


Data-centered  systems: 

•  Transactional  Database  Systems  -  central  data  repository/query  driven 

•  Blackboards  -  central  shared  representation/opportunistic  execution 


Reference:  Garlan,  Shaw  -  ‘An  Introduction  to  Software  Architecture'  to  appear  in  Advances  in  Software 
Eng.  and  Knowledge  Eng.,  vol.1 1993 
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Roadmap  for  this  Session 


Architecture  “Defined” 

Towards  a  Science  of  Architecture 

Trends  in  Architecture  for  Reuse 

Architecture-Based  Reuse 
Systems 


_  •  phenomenology 

’***'  •  externally  visible  qualities  of 

architecture:  a  hypothesis 

•  Idnda  of  architectures 


•  object-oriented  architectures 

**  •  event-based  architectures 

•  object-ortent ed/event  hybrids 

•  overview  of  concepts 

•  analogy  with  configuration 
management 
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What  Kinds  of  Architectures  Best  Support  Reuse? 


Object-oriented  systems 

•  how  do  they  support  reuse? 

•  trends 

Event  systems 

•  what  are  the  key  ideas? 

•  why  do  they  support  reuse? 

•  trends 
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What  Kinds  of  Software  Architecture  Support  Reuse? 


An  architecture  that  has  a  mixture  of  object-oriented  and  event  systems  characteristics  is  best  suited  lor 
supporting  reuse  of  design  and  code  in  our  view.  The  following  part  of  the  presentation  will  dscuss  these 
architecture  styles  in  more  detail.  There  has  been  an  explosion  in  object-oriented  systems  in  the  last 
decade  and  it  is  assumed  that  most  of  the  audienoe  is  lamiBar  with  the  basic  concepts.  Event  systems  are 
less  well  known  so  more  background  will  be  given. 


Object-Oriented  Systems  -  Why? 


Key  reuse  mechanisms: 

•  objects 

•  encapsulation 
-  abstraction 

•  classes 

•  inheritance 

•  mechanisms  scaled-up  to  large 
objects 
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Object-Oriented  Systems  -  Why? 


Objects  facilitate  modeing  the  work!  directly  in  software  thus  making  a  system  easier  to  understand.  They 
hide  details  (abstraction).  Objects  reduce  coupling  and  therefore  reduce  the  propagation  of  changes. 
Objects  are  more  independent  from  the  context  of  a  system  and  therefore  probably  more  reusable. 


Classes  group  objects  tor  ease  of  understanding.  Inheritance  reduces  duplication  of  design/code  and 
allows  extension  of  existing  classes  into  new  subclasses. 


In  the  context  of  architectures  and  mega-programming  we  are  not  taking  about  small  data  structure 
objects  (code  level).  We  are  talking  about  large  components  or  subsystems  (e.g.  stand-alone  tools). 


The  disadvantage  of  00  systems  is  that  objects  have  to  know  the  names  of  the  operations  in  other  objects. 
References: 

Gaftan,  Shaw  -  "An  Introduction  to  Software  Architecture*  to  appear  in  Advances  in  Software  Eng.  and 
Knowledge  Eng.,  vd.1  1998 

Booch  -  "Object-Oriented  Design  with  Applications’  Berjamin  Cummings  1991 
Meyer  B.  ‘Object-Oriented  Software  Construction*  Prentice-Hall  1988 
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Object-Oriented  Systems  -  Trends 


Object-Oriented  Trends 


Common  object  semantics:  The  Object  Management  Group  has  da veloped an  object  modal  (m  part otthe  Common  Object 
Raqueet  Broker  Architecture  CORBA)  which  attempts  to  standardize  object  management  setvicee  acroaa  heterogeneous 
platforms  and  aatabiah  common  tacikDaa  (standard  ganaral  utiity  objects  ■  a.g.  edhors,  hep  facilities,  e-mail).  This  a  dona 
by  aatabfiaHng  atandaid  objact  intaiiacaa(aignaturaa)  which  tnduda  operations  and  pammatara.  Tha  objact  modal  would 
promote  extensive  rnuaa  of  ganaral  object*.  Tha  6EI  fa  pureung  tha  idea  of  common  aignaturaa  to  tha  context  of  a  specific 
domain.  Thi*  ehottid  prove  to  be  a  powerful  rouee  approach. 

Standard  daaign  representations:  Curantty  their  ia  a  proliferation  of  object-oriented  deeign  rapraaantabona  (graphic*  and 
toxO-  Developing  a  atandaid  rapraaentation  would  greatly  faciiitata  Iha  rauaa  of  deaigrVood*. 

Pattamr.  Raeearcher*  are  beginning  to  identity  and  catalog  pattama  (micro-arch itacturaa)  in  object-oriented  ayatama.  These 
pattama  are  organized  in  a  taxonomy  and  have  a  standard  documentation  templet*  that  may  toduds:  intent,  motivation, 
appicabKty,  participant*,  colaboratioiw,  dagrams,  consequences,  implementation,  examples,  and  'see  also*.  These 
pattama  wtii  help  develop  and  taciiitate  understanding  of  software  architectixss  lor  whole  ayatama. 

Frameworks:  Object-oriented  framework*  are  ftextol*  configurations  of  component*  (component  desses)  connected  by  data 
tow.  Frameworks  have  many  of  tiie  charactanstrca  of  a  software  architecture.  Researchers  are  aqrehmenting  with  the 
appticalion  of  frameworks  to  various  domains. 

OMG  "Object  Management  ArcMtecture  QuMe*  8ept  1992 

Peterson,  Stanley  Utepplng  s  Domain  Mods!  and  Architecture  to  a  Generic  Deeign*  CMUWEt-TR  draft 

Booth  "Next  Generation  Methods  -  Brtnpng  Ordsr  ouf  or  toe  Cheos’  Journal  of  Object  Oriented  Programming  •  Supplement  on  OO 
Analysis  and  Deeign  JulyfAugust  1993 

Taft  "Ads  9X:  A  Tsehnicsl  Summary*  Comminkatlons  of  the  ACM,  Nor.  1992 

Gamma,  £.,  Helm,  R,  Johnson,  R.,  Vlieafdee,  R.,  Design  Pattama:  "Attraction  and  Rauae  of  Object  Oriented  Deeign"— unpublished 
paper.  Contact  Bitch  Gemma  si  T (tiger!,  Inc.,  10723  N.  Os  Ante  Blvd.,  Cupertino,  CA  95014-2000 

Harass! i.  Gibbs,  TsJehrttzis  "Compontnt  Oriented  Software  Development",  Communications  of  toe  ACM,  Vd.  35.  No.  9  Sept  1 992. 
Buechmann  "Rational  archilactures  ter  object-oriented  sottwars  tyttams*  Journal  ef  Object-Oriented  Programming,  Sept.  1 9S3 
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Object-Oriented  Framework:  Example 
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Object-Oriented  Framework:  Example 

An  OO  framework  is  both  a  reusable  architecture  and  an  architecture  that  supports  reuse  of  components.  This  particular 
framework  is  for  a  generic  material  flow  control  system  which  is  part  of  a  larger  framework  for  flexible  manufacturing 
systems.  The  basic  structure  and  relationships  between  elements  (component  classes)  can  be  reused  regardless  of  the  spe¬ 
cific  work  pieces  being  transported.  Basic  operations  and  data  fi  e.  signatures)  are  defined  at  an  abstract  level  for  the 
domain. 


References: 

Buschmann  "Rational  architectures  for  object-oriented  software  systems'  Journal  of  Object-Oriented  Pro¬ 
gramming,  Sept.  1993 


Object-Oriented  Framework:  Example  Adaptation 
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Object-Oriented  Framework:  Example  Adaptation 

An  OO  framework  can  be  designed  to  be  adaptable  and  flexible  ao  that  new  objects  or  subsystems  can  be  grafted  in  or 
removed.  The  top  part  of  the  slide  shows  the  basic  ftamework.  The  bottom  part  of  the  slide  shows  several  new  objects 
grafted  in. 

References: 

Nierstrasz,  Gibbs.  Tstchrrtzts  ‘Component  Oriented  Software  Development",  Communications  of  the  ACM, 
Vol.  35.  No.  9  Sept.  1992. 
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Event  Systems  -  Key  Ideas 


Event  Manager 


Components 


Components  can  announce  (broadcast)  events. 

Components  can  register  for  events  of  interest 
and  associate  operations  with  them. 


Upon  event  announcement  the  corresponding 
operations  are  automatically  invoked  (by  the 
system). 


•  Hence,  invocation  is  implicit,  although  explicit 
invocation  is  often  still  provided. 
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Event  Systems  -  Key  Ideas 


Event  systems  are  emerging  as  an  important  architecture  for  integrating  diverse  components  (objects  or 
modules).  Many  event  systems  are  also  object-oriented.  They  may  also  allow  explicit  invocation  (direct 
cals)  to  control  the  flow  of  execution. 

References: 


David  Garian  and  Curtis  Soott 

Adding  Implicit  Invocation  to  Traditional  Programming  Languages 
Proceedings  of  The  15th  International  Conference  on  Software  Engineering 
May  17-21 . 1993  Baltimore,  MD,  pp.  447-455. 

David  Garian  and  Mary  Shaw 
An  Introduction  to  Software  Architecture 

To  appear  in  Advances  in  Software  Engineering  and  Knowledge  Engineering,  Volume  I 
World  Scientific  Publishing  Co,  1993. 

David  Garian,  Gail  E.  Kaiser  and  David  Nolen 
Using  Tool  Abstraction  to  Compose  Systems 
IEEE  Computer,  June  1992,  pp.  30-38 


Assume  Operation  A1  Is  called.  This  results  In  the  announcement  of  event  y. 

The  system  register  (event  manager)  shows  that  both  Object  B  and 
Object  C  can  respond. 

Object  B  would  Invoke  Operation  Bl ; 

Object  C  would  Invoke  Operation  Cl. 


If  the  system  does  not  choose  one  over  the  other, 
then  "Implicit  Invocation"  will  be  output  (In  some  order). 
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Evolution  of  Implicit  Invocation 


Evolution  of  Implicit  Invocation 

A  main  source  of  ideas  lor  event  systems  was  research  on  (SEE)  Tool  Integration  Frameworks.These  SEE 
integrated  frameworks  are  usualy  a  collection  of  tools  running  as  separate  processes.  Event  are  broadcast 
via  separate  dispatcher  process.  Communication  channels  are  provided  by  host  OS  (e.g..  Unix  sockets). 

The  ideas  behind  event  systems  also  show  up  in  special  purpose  languages  and  application  frameworks 
which  provide  access  through  special  notations  and  runtime  support.  Examples  include:  active  data  trig¬ 
gers  for  a  DBMS,  spreadsheets  (via  dependency  facts),  and  production  systems  for  expert  advice. 

General  purpose  event  systems  are  beginning  to  emerge.  They  are  being  built  within  general  purpose 
language  environments  lire  Ada.  The  Common  Object  Request  Broker  Architecture  (CORBA)  is  an 
emerging  standard  for  event  system  architectures  across  heterogeneous  platforms.  The  Object 
Connection  Architecture  (OCA)  is  a  generalization  of  the  Object  Connection  Update  (OCU)  model 
originally  developed  for  the  flight  simulator  domain  (the  OCA  is  related  to  the  event  system  architecture). 

References: 

Garlan,  Scott  'Adding  Implicit  Invocation  to  Traditional  Programming  Languages'  15th  ICSE 
OMG  "Object  Management  Architecture  Guide’  SepL  1992 

Peterson,  Stanley  ‘Mapping  a  Domain  Model  and  Architecture  to  a  Generic  Design'  CMU/SEI-TR  draft 
Lee,  Rissman,  D’lppdito,  Plinta,  Van  Scoy  'An  OOD  Paradigm  for  Flight  Simulators"  CMU/SEI-88-TR-30 
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Event  Systems:  Advantages 


•  Provides  significant  support  for  reuse: 

-  Can  integrate  components  simply  by  registering  their  interest 
in  the  events  of  the  system. 

•  Eases  system  evolution: 

•  Loose  coupling  helps  eliminate  name  dependencies  between 
components. 

-  Can  add  /  replace  components  without  interfering  with  existing 
objects. 

-  Changes  localized  to  system  register  /  event  manager. 

•  Upward  compatible. 

•  Can  still  have  explicit  invocation. 


This  pace  intentionally  left  blank. 
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Event  Systems:  Disadvantages 


•  Indirection  overhead  may  be  high. 

•  Special  purpose  languages  for  event  broadcast  are  limited  by  definition. 

•  Components  relinquish  control  over  the  overall  computation. 

•  A  component  does  not  know:  “who”  will  respond  or  the  order  and  com¬ 
pletion  of  invocations,  so  cycles  could  result 

•  Hard  to  reason  about  correctness. 


TThs  page  intentionally  left  blank. 
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Event  Systems  -  Trends 


Improved 

Reuse 


Event  Systems  - Trends 


Continued  research  is  needed  to  explore  the  design  qwce  of  event  system  mechanisms  and  to  fine  tune  them  for  specific 
cUsjcs  of  applications.  Ongoing  research  is  also  addressing  the  process  of  developing  systems  based  on  the  event  system 
model. 

References: 

Garian,  Scott  'Adding  Implicit  Invocation  to  Traditional  Programming  Languages'  15th  ICSE 
Peterson.  Stanley  ‘Mapping  a  Domain  Model  and  Architecture  to  a  Generic  Design*  CMU/SEI-TR  draft 


CORBA 

The  Object  Management  Group  (OMG)  is  working  on  a  landsrdizing  the  interface*  to  to  object  request  broker  within  the 
Common  Object  Request  Broker  Architecture  (CORBA).  OMG  has  developed  an  interface  definition  language  (IDL) 
that  looks  a  lot  like  C++.  Binding  to  the  IDL  can  be  written  in  other  languages  (a  C  binding  exists  now).  The  OMG  has 
also  defined  a  Basic  Object  Adapter  which  provides  standard  “glue”  (L e»  a  wrapper)  so  that  components  can  be  integrated 
into  a  CORBA  based  heterogeneous  system.  Special  purpose  adapters  can  also  be  defined.  CORBA  is  still  evolving. 

References: 

OMG  “The  Common  Object  Request  Broker:  Architecture  and  Specification”  1 992 
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Hybrid  Architecture:  E vent/Data-centered  System 


Hybrid  Architectures:  Event/Data-centered  System 

Large  systems  often  are  made  up  of  components  that  have  combined  architecture  styles.  This  diagram 
shows  a  popular  hybrid  architecture  tor  software  engineering  environments  where  the  two  styles  are  com- 
ptimentary.  Control  integration  is  achieved  through  event  system  mechanisms  whereas  a  data -centered 
mechanism  (repository)  facilitates  data  integration. 

Reference:  Garian,  Shaw  -  ‘An  Introduction  to  Software  Architecture*  to  appear  in  Advances  in  Software 
Eng.  and  Knowledge  Eng.,  vol.1 1993 
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Architectures  for  Reuse  -  Summary 


/  maximum 
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1  reuse 

systems 
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1  systems / 
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Architectures  for  Reuse  -  Summary 

As  of  Isle  1 993  object-oriented  and  event  systems  appear  to  be  the  most  promising  architecture  styles  far  accomplishing 
large  scale  reuse.  CORBA  is  an  important  initiative  that  should  tsdlitaie  the  cost-effective  adoption  of  a  hybrid  object- 
oriented  event  system  architecture.  CORBA  is  also  attempting  to  address  a  few  other  important  issues  such  as  interna¬ 
tionalization  (multi-lingual  and  multi-cultural  issues). 
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Roadmap  for  this  Session 


Architecture  uDefined” 

Towards  a  Science  of  Architecture 


•  phenomenology 

•  externally  vMbia  quaHtfaa  of 
architecture:  a  hypothaala 

•  Mixta  of  aicNtecairea 


Trends  in  Architecture  for  Reuse 

Architecture- Based  Reuse 
Systems 


.  •  object -orient  ad  arcMtecturea 

**  •  event-baaed  architectures 

•  object  ortantad/evcnt  liybrtda 

•  overview  of  concepta 

•  analogy  wttfi  configuration 
managamant 
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Sometimes  H  is  usehJ  to  imagine  the  extremities  of  a  concept  (e.g.,  'reducSo  ad  atsurdunf). 

Is  this  pinball  constructor  Wt  perhaps  the  ultimate  in  architecture-based  reuse  environments7  It  seems  to 
have  many  of  the  elements  we  would  expect:  a  buat-in  application  framework,  sets  of  components,  rules 
for  construction,  automated  support  tor  construction,  mechanisms  tor  connecting  components,  etc. 

In  this  example,  the  user  of  the  reuse  system  is  the  application  end  user.  Would  it  be  unreasonable  to  ex¬ 
pect  the  end  user  of.  say.  a  command  and  control  command  center  to  similarly  -compose-  the  activity  cen¬ 
ters,  screens  and  information  flow  among  screens  and  activity  centers  within  a  command  center?  In  the 

near  term  this  may  not  be  feasible  due  to  the  complexity  of  the  appScaten,  the  dependency  of  system  fimc- 

ti°n  on  events  and  time,  the  impact  of  mission  and  doctrine,  etc.,  on  the  end  application 
References 

Pinball  Constructor:  photocopy  of  a  product  jacket  for  commercially-avaiable  personal  computer  applies- 


Architecture-Based  Systems  for  the  System  Designer 


The  previous  example  iilustraled  architecture-based  services  for  the  end  user  of  the  application;  we  nvght 
view  the  previous  example  as  more  of  a  Tailor  able  application"  than  architecture-based  reuse  system. 

But  what  if  we  target  6uch  a  system  not  tor  the  appication  end-user,  but  tor  its  designer?  In  this  case  the 
system  could  move  one  notch  closer  to  the  implementation  abstractions.  In  Ms  llustration  two  systems 
horn  the  Crack  project  demonstrate  the  concept  nicely.  The  system  depicted  on  the  left  is  a  design  assis¬ 
tant  lor  human-machine  interfaces  (HMI),  while  the  system  on  the  right  is  targeted  to  kitchen  design.  Al¬ 
though  we  are  stil  not  at  the  level  of  command  center,  these  systems  minor  some  ol  the  capabfflties  of  the 
pinball  constructor:  a  set  ol  design  elements,  in  these  cases  targeted  to  application  designers;  rules  for 
composition;  a  compositiorirconstruction  area.  etc. 

Note  that  in  these  examples  the  design  elements  are  "domain-specific.'  This  was  true  of  the  pinbal  con¬ 
structor  (flippers,  bells,  balls,  etc.),  the  window  design  assistant  (dsplay,  scrollers,  etc.)  and  the  kitchen 
design  assistant  (doors,  sinks,  stoves,  etc.).  But  what  if  we  substitute  fa  domain-specific  design  elements 
the  components,  or  design  elements,  of  an  architecture  style  (a  architecture  model)?  We  may  find  our¬ 
selves  in  an  environment  such  as  that  provided  by  several  CASE  vendors  (StateMate,  UNAS/SALE). 

References 

Gerhard  Fischer,  "Human  Computer  Interaction  Software:  Lessons  Learned,  Challenges  Ahead,"  IEEE 
Software,  January  1969. 
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Architecture-Based  Systems  for  the  Programmer? 

This  final  example  illustrates  yet  another  concept  of  architecture-based  reuse  system.  Where  the  pinball 
constructor  was  targeted  to  end  users,  and  the  kitchen  design  assistant  targeted  to  a  system  designer,  the 
Apple  Macintosh  MacAPP  represents  an  architecture-based  reuse  system  targeted  to  programmers.  This 
figure  is  copied  from  the  MacAPP  documentation,  and  illustrates  the  use  of  an  architecture  as  a  template, 
or  framework,  into  which  appication -specific  functionality  are  inserted.  In  this  case  the  application  archi¬ 
tecture  is  (more  or  less)  "fixecT— much  of  the  hard  design  work  has  been  encoded  in  the  application  tem¬ 
plate. 

What  this  succession  of  examples  illustrates  is  that  there  is  a  range  of  possible  manifestations  of  'archi¬ 
tecture-based  reuse  system.'  Moreover,  these  illustrates  only  varied  the  intended  user  of  the  system; 
many  other  dimensions  of  variability  are  possible. 

A  more  general  way  of  thinking  about  architecture-based  reuse  systems  is  to  think  of  such  systems  as  the 
means  of  conveying  the  results  of  a  domain-engineering  life  cycle  to  many  possible  application  engineer¬ 
ing  life  cycles.  Since  the  nature  of  each  life  cycle  wil  vary  depending  upon  domain,  engineering  infrastruc¬ 
ture  technologies  (i.e.,  software  development  environment  tooling),  local  cultures,  etc.,  the  associated 
reuse  systems  wil  also  vary. 

References 

Apple  Macintosh  MacAPP  Developer's  Kit  Documentation. 
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Reuse  Environment:  Integrating  Domain  and 
Application  Engineering  Life  Cycles 


Reuse  Environment:  Integrating  Domain  and 
Application  Engineering  Life  Cycles 

The  reuse  environment  is  not  simply  an  application  building  environment,  it  is  a  set  of  mechanisms  and 
reusable  products  that  alow  us.  in  effect  to  integrate  domain  engineering  and  application  engineering  pro¬ 
cesses. 

Domain  specific  reuse  is  generaly  acknowledged  to  consist  of  two  separate  fife  cycles:  the  domain  engi¬ 
neering  fife  cycle,  and  toe  application  engineering  fife  cycle. 

Some  mechanisms  must  be  present  in  order  to  transfer  toe  results  of  domain  engineering  to  application 
engineering— the  packaging  of  reuse  products,  toe  tools  and  documentation  needed  to  apply  these  prod¬ 
ucts. 

The  chart  lustrates  toe  addrtion  of  a  process  dimension  to  this  packaging.  That  is,  toe  kinds  of  reusable 
products  which  flow  from  domain  engineering  to  application  engineering  will  depend  upon  the  internal  pro¬ 
cesses  implied,  or  required,  by  each  file  cycle  model.  This  chart  Mustrates  just  one  of  many  possible  mod¬ 
els. 

Reference: 

T.  Payton,  "Domain-Specific  Reuse,"  STARS  92  Annotated  Briefing  Chart,  pp.  16-17.  This  chart  is  an  in¬ 
terpreted  rendering  of  one  found  m  the  STARS  92  proceedings. 
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A  DSSA  View  of  Architecture-Based  Reuse  Systems 


Domain 

Architect 


tnstantlgt9d 

Archtfrctun 


Operator 


A  DSSA  View  of  Architecture-Based  Reuse  Systems 

This  chart  Uustretes  the  ARPA/DSSA  view  of  architecture-based  reuse  systems.  The  chart  is  copied  horn 
a  ARPA/DSSA  presentation — the  shaded  box  which  highlights  Vie  application-specific  development  envi¬ 
ronment  has  been  added  to  emphasize  that  in  our  discussions  we  are  concerned  with  the  tools  and  envi¬ 
ronments  delivered  to  application  developers,  and  not  with  Vie  toots  and  environments  necessary  to 
conduct  domain  engineering  activities. 

References 

U.Coi.  Eric  Matetla,  'Domain-Specific  Software  Architectures,’  STARS  92  annotated  briefing,  pp.  90-116. 
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Reuse  Techniques  and  Architecture 


Transformational 

•  formalisms  and  mappings 

•  generators— implicit  transforms 

•  assistants  explicit  transforms 

wtth  guidance  for  human  Intervention 


Compositional 

•  module  building  blocks 

•  moatiy  manual  construction 

•  standard  shapes  or  profit  by  assign 


So  whom  Is  the  “architecture?”  (aka.  reference  architecture,  application 
framework,...) 

—  pure  transformational:  In  the  transformation  rules  and  languages 
—pure  compositional:  In  the  form  and  function  of  components 
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Reuse  Techniques  and  Architecture 

We  need  to  factor  in  another  <fimen6ion  in  order  to  really  understand  the  impfications  of  the  DSSA  picture 
for  domain-specific  application  engineering  environments-  The  exact  form  and  content  of  reference  archi¬ 
tectures,  components  and  tools  wil  be  dependant  upon  the  basic  reuse  technology  approaches  taken.  Big- 
gerstalf  and  others  have  defined  taxonomies  of  reuse  approaches.  Without  getting  into  neerfiess  detail,  a 
top-level  partitioning  of  approaches  is  the  transformationaVcompositionai  cfichotomy. 

The  transformational  approach  is  characterized  by  a  sequence  of  transformations  among  representations, 
with  each  transformation  bringing  the  representation  towards  closer  to  some  final  stale.  Two  major  classes 
ol  transformational  systems  are: 

1 )  generators:  systems  where  the  transformations  are  invisible/automatic  (or,  more  commonly,  there  is 
only  one  automated  transformation  step). 

2)  krv  vtedge-based  assistants:  systems  where  there  are  multiple  transformations,  perhaps  but  not 
necessarily  through  dttferent  representations,  and  where  the  transformations  are  visible  to  the  “user" 
and  where  there  is  guidance  provided  by  the  system  to  assist  in  performing  the  transformation. 

The  compucitional  approach  is  characterized  by  reuse  through  manual  composition  of  concrete  code  com¬ 
ponents.  Erthtr  families  of  components  are  developed  (e  g.,  GRACE  components)  or  highly-parameterized 
components  are  tsvelof red.  In  either  case  there  is  little  scope  tor  ‘automation.* 

Interestingly,  in  both  ‘extremes'  the  question  of  “where  is  the  architecture’  is  the  same:  the  architecture  is 
implicitly  represented.  In  the  case  of  the  transformation  approach  the  architecture  is  found  in  the  patterns 
locked  in  code  generators,  in  the  terminology  of  the  languages,  and  the  rules  for  creating  sentential  forms. 
In  the  composition  approach  the  architecture  is  again  implicit,  or.  at  best,  reflected  in  the  structure/form 
(i.e.,  interfaces  and  function)  of  the  components. 

The  use  ol  software  architecture  can  help  achieve  the  benefits  ol  both  approaches  in  a  hybrid  strategy.*04 
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Hypothetical  Impact  Analysis 

Although  there  are  no  sotid  economic  models  to  draw  upon,  there  is  general  consensus  within  the  reuse 
community  that,  all  else  being  equal,  generative  reuse  techniques  wa  yield  more  dramatic  reuse  results 
than  a  purely  compositional  approach. 

The  chart  fflustrates  a  hypothetical  curve,  with  the  area  under  the  curve  being  ‘economic  impact"  No  scale 
or  measures  are  intended,  and  the  picture  is  not  meant  to  imply  any  precision:  the  "shape”  of  the  curve  is 
a  guess.  However,  a  number  of  factors  support  the  general  hypothesis  that  hybrid  reuse  may  provide,  in 
practice,  the  biggest  bang-for-the-buck: 

1)  Wile  generative  reuse  would  be  ideal,  such  generators  can  be  extremely  expensive  to  develop,  and 
may  only  be  effective  in  highly  stable  application  domains.  The  most  frequently  appfied  application  of  gen¬ 
erational  technology  is  through  "application  specific  languages"  for  pieces  ("subdomains")  of  application 
domains,  e.g.,  message  formal  processing  systems,  human-machine  interface  subsystems,  form/report 
generation  subsystems,  are  just  a  few  examples. 

2)  Compositional  reuse  is  still  a  labor  intensive  activity,  and  it  is  cfffcutt  to  develop  a  sufficiently  "dense" 
population  of  components  to  satisfy  diverse  application  requirements. 

Idealy,  then,  we  wish  to  develop  reuse  technologies  which  support  the  opportunistic  hybridization  of  gen¬ 
erative  reuse  with  compositional  reuse,  whomever  possible.  Domain-specific  software  architectures  can 
provide  a  mechanism  for  coherent  integration  of  compositional  and  generational  reuse,  and,  perhaps,  a 
migration  path  towards  increasing  use  of  generative  techniques  within  application  domains. 

References: 

Martin  Griss,  Informal  Presentation  Charts,  W1SR6,  Owego  NY,  Nov.  3-5 1993. 
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Hybrid-Reuse  Strategies  Centered  on  Architectures 

We've  taken  some  fibedies  with  Wustrations  from  ARPA/DSSA  presentations  on  this  slide— we  befieve  it 
reflects  some  important  points  of  the  ARPAfDSSA  approach,  bU  it  should  be  noted  that  this  picture  is  equal 
part  ^plagiarism*  and  Interpretation’ 

The  basic  tenant  is  that  a  reference  architecture  can  be  defined  which  represents  a  "partial  application*  in 
the  domain.  One  analogy  used  to  describe  the  reference  architecture  is  as  a  ‘design  with  holes  in  it,*  with 
design  refinement  as  the  means  oi  *fffling  the  holes.*  In  some  cases  the  hole  can  be  filed  by  generating  a 
component,  ot  aeiecfing^adapting  a  component  from  a  component  library.  In  other  cases  the  hole  may  be 
tiled  by  selecting  among  various  design  alternatives,  each  alternative  adding  information  to  the  design  but, 
potentialy,  also  introducing  “new  holes*  which  need  to  be  filed. 

It  needs  to  be  noted  that  this  picture,  though  rich  in  concept,  represents  one  common  perspective  from  the 
OSSA  program— deferent  member  projects  each  have  refined  the  meaning  of  this  picture  using  different 
technologies  and  processes.  In  at  least  one  case  the  reference  software  architecture  appears  in  the  -mkl- 
dte*  of  a  detailed  system  development  process  including  hardware,  controlers  and  software.  The  DSSA 
program  has  lustraled  that  the  domain- specific  application  engineering  environment  does  need  to  vary 
accortfing  to  the  problem  domain,  common  engineering  practice  within  the  domain  and  cultural  factors. 

References 

U.Col.  Eric  Matefia,  Domain-Specific  Software  Architectures,'  in  proceedings  of  STARS  92  Conference, 
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Hybrid  Architecture-Based  Reuse  and  Compositional  CM 

Evan  without  getting  into  the  details  of  specific  domain-specific  application  engineering  environments,  it  is 
possible  to  understand  some  of  the  information  management  requirements  introduced  by  this  model  of  hy¬ 
brid.  architecture-based  reuse.  One  way  to  expose  some  of  these  issues  is  to  compare  the  hybrid  reuse 
approach  with  the  relatively  mature  discipline  of  configuration  management  (CM). 

Ilustrated  on  this  chart  are  some  of  the  key  principles  behind  a  model  of  CM  referred  to  as  ‘compositional 
CM*  in  a  paper  by  Feiler.  The  key  elements  of  compositional  CM  are:  1)  a  system  model,  2)  a  version  space 
of  sources,  and  3)  selection  rules.  There  is  great  flexibility  in  the  realization  of  this  model  (in  fact.  1  and  2 
can  be  combined).  As  Ilustrated  by  Feiler,  the  this  CM  model  appears  in  a  number  of  commercial  products. 

The  system  model  reflects  the  structure  of  an  application— here  modeled  as  a  simple  ‘and/or  graph  with 
"or  denoted  as  V  and  "and"  denoted  by  the  absence  of  a  symbol.  The  interpretation  is  straightforward:  a 
system  is  oomposed  of  A  and  B.  with  A  composed  either  of  variant  C  or  D,  etc.  (It  is  important  to  note  that 
we  need  not  have  such  a  representation,  but  it  is  convenient  for  the  analogy.)  Eventually,  leaf  nodes  on 
the  graph  refer  to  concrete  objects  in  the  version  space. 

The  selection  rules  can  be  primitive,  e.g.,  an  enumeration  of  the  objects  in  the  version  space  which  belong 
to  a  configuration,  or  can  be  more  elaborate.  For  example,  one  use  of  the  and/or  structure  could  be  to  mir¬ 
ror  the  hierarchical  relationships  in  the  system  design,  and  could  be  ‘decorated’  with  attributes  which  could 
then  be  used  in  selection  rules  as  predicates,  e.g.,  configuration  version  1  is  such  that  we  select  versions 
where  TESTED-TRUE  and  HOST-VAX.  It  is  easy  to  see  how  a  tamiy  of  systems  can  be  enumerated. 

For  the  purposes  of  the  analogy,  we  will  equate  system  model  with  reference  architecture,  version  space 
with  component  Itorary,  and  selection  rules  with  refinement  rules. 

Peter  Feiler,  Configuration  Management  Models  in  Commercial  Environments,  Technical  Report 
CMU/SEI-91  -TR-7,  Software  Engineering  Institute,  Carnegie  Mellon  University,  Pittsburgh,  PA. 
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Hybrid  Architecture-Based  Reuse  and  Compositional  CM 

Oir  contention  is  tiat  in  many  ways  the  hybrid  architecture-based  rouse  approach  mirrors  that  at  composi¬ 
tional  CM.  The  Mowing  rfichotomies  serve  to  Uustrate  these  differences,  and  shed  light  on  the  technology 
considerations  involved  in  architecture-based  reuse  systems: 

Problem  and -Solution  sms  mam,  system  bu bt  Architechjre-besed  reuse  involveB  managing  complex  de¬ 
sign  trade-oils  and  making  decisions  negaRfing  which  design  decisions  to  make,  which  components  to  inte¬ 
grate.  etc.  This  requires  detailed  information  about  the  problem  space.  In  contrast,  CM  manages  objects  in 
the  solution  space. 

imwnsional  configurations  versus  adatttiCPal  configurations:  For  archrtecfurB-hasad  muse  we  do  not  want  to 
have  to  enumerate  all  possible  configurations,  but  rather  define  the  rules  tor  creating  new  instances. 

EagfiCit  interaction  versus  implicit  teatira  interaction:  CM  is  not  a  design  tfeciniine:  there  is  no  inherent 

need  to  capture  alof  the  complex  interdependencies  among  components  (see  “intensionai  configurations'). 
Note:  there  are  gray  areas,  such  as  Tartan's  Configurafion  Management  Assistant. 

Manaabtft  mmponant  form  versus  fixed  component  tom:  if  the  context  in  which  components  are  reused  is 
changing,  there  is  an  increasing  need  for  these  components  to  be  adaptable  to  these  changing  contexts.  This 
is  one  motivation  for  research  into  module  interconnection  languages. 

tncnmptetaness  versus  completeness:  By  definition,  a  reterenoe  architecture  is  incomplete.  This  implies  that 
refinement  and  composition  tools  will  need  to  accommodate,  track  and  manage  incompleteness. 
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Hybrid  Architecture-Based  Reuse  and  Compositional  CM 

)!BgjtitiatxxymBm£tuUBa&  See  incompleteness.  Than#  am  some  references  with  incompleteness, 
mainly  unowned  wi*i  the  interaction  ol  Mum  and  design  refinements  which  may  oocu  as  a  resrit  of 
reining  several  aspects  of  a  design  sirmilenoously  (as  Mon  a  design  agenda).  It  wll  be  necessary  to  man- 
age  inconsistencies;  H  may  even  be  desimble  to  an ow  inconsistency.  (Inoompleteness  can  be  taught  of 
as  a  severs  form  of  inoon^stoncy) 

ftyrtam  and  mnaramantuMK  ron>>r»  r»tWyi  atirtit-  Ac  ritxafjnc  am  radnofi  than,  m.«rt  ha  . 

wayot  evaluating  the  partial  and  completed  products.  The  engineering  practices  tor  evaluation  wiMdffler. 
by  domain;  tie  evaluation  of  configurations  is  mom  concerned  wMh  completeness  and  consistency. 

MiSti-narty  nnSahnnuinn  wmis  mirt-nafty  control:  Both  CM  and  architecture-b8sed  reuse  systems  ad¬ 
dress  ta  existence  oimuftipte  parties  maMng  changes  to  shared  representations.  However,  the  emphasis 
In  CM  Is  on  change  control  and  change  management,  whle  architecture-baaed  reuse  systems  wM  invoive 
more  elements  o(  computer-supported  cooperative  work.  This  is  not  unexpected  sinoe  the  architecture- 
based  muse  system  is  lady  to  emphasize  aspects  ol  coMaboraave  and  exploratory  design. 

Lana  treneariions  versus  short  transactions.  While  CM  may  enoompass  some  aspects  of  coouSnafeng 
change  among  multiple  parties,  the  construction  of  compositions  from  a  CM  system  can  be  taught  of  as 
more  or  less  atomic.  However,  real  systems  design  takes  place  over  an  extended  time,  and  may  invoive 
multiple  parlies,  with  backouts,  checkpoints,  etc. 

(lltinnQIK 

Pater  Falter,  ConBguration  Managamanl  Modaia  In  Comma rbal  Environmanti,  Tachnical  Raport  CMU/SEI-91-TR-7,  Sott- 
wara  Enginaartng  Inattute,  Camagia  Mallon  Urivaralty,  Ptttebuyh,  PA. 

R.  Baizar,  *Daaign  Rafinamant  In  DSSAa,'  in  prooaadinga  oi  ttw  JSQCC  Softwara  Initiativa  Strategy  Wortcahop,  Dac.  1992. 
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Influences  on  Selection  of  Exemplar  Systems 

A  number  of  consequences  on  technology  lor  architecture-based  retm  systems  can  be  discerned  from 
the  NrheeT  diagram  on  tw  previous  chart  Two  key  ideas  emerge  which  efitferentiate  archriectwe-based 
reuse  systems  tram  compositional  CM  systems:  the  locus  on  problem  solving  support  and  managing  cog¬ 
nitive  complexity  fcom  scale. 

Both  ol  these  together  may  imply  some  use  ot  formal  modeling— inducing  both  knowledge  representation 
and  more  mathematical.  La.,  algebraic,  representations.  Even  H  this  implication  is  not  accepted  by  the 
reader,  it  is  certainly  he  case  that  the  topic  ot  architectm-besed  design  assistants  and  domain-specific 
archiectures  is  attracting  the  attention  ot  researchers  in  artificial  intefigenoe  and  formal  methods.  Naturefiy 
this  has  influenced  our  selection  ot  tools  lor  evaluation  pupoees. 

Note:  The  reason  why  we  have  endeavored  to  examine  these  exemplar  systems,  which 
wflt  be  dscussed  in  the  next  session  in  detal,  wtt  be  dtedosed  in  Session  V: 

CARDS  and  Software  Architecture. 

A  second  oontrttuting  factor  is,  ol  come,  our  own  program  biases,  based  in  large  part  on  the  technology 
foundations  used  by  CARDS  to  build  architecture-based  reuse  library  systems.  This  base  technology 
draws  heavily  upon  knowledge  representation  systems,  and  demonstrates  the  development  ot  automated 
reuse  assistants  tor  DoO  software-intensive  appfications. 


Central  Archive  for  Reusable 
Defense  Software 
(CARDS) 


Session  IV 

Architecture-Based  Reuse  Tools 


16  November  1993 


This  paQe  intentionaJiy  loft  Wank. 
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Architecture  Based  Reuse  Tools 


•  Pioneers: 

-  Draco 

-  ROSE-2 


Current: 

•  LaSSIE 

•  KAPTUR 

-  UNAS 

-  Technology  Book 

Emerging: 

•  LILEANNA 

•  p.Rapide 

Future: 

-  Integrated  tools  and  libraries 
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Architecture  Based  Reuse  Tools 


The  purpoGfl  of  this  session  i6  to  survey  some  representative  tools  which  si  least  parhaly  support 
architecture  based  reuse.  This  can  be  considered  a  mini-domain  analysis  d  architecture  based  reuse 
tools.  First  we  took  at  eome  early  pioneers  to  give  an  historical  oontexL  Then  we  look  atasample  of  current 
tools  (proprietary  and  available  to  the  public).  Next  tools  emerging  from  the  research  community  are 
examined  because  they  may  fil  gaps  in  existing  capabilities,  finally,  we  look  at  tie  vision  for  the  future. 
For  each  tool  we  wil  describe  key  concepts,  architecture  representations,  tool  functionality,  and  lessons 
learned. 
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•  Early  example  of  architecture  based  reuse  tool 

•  A  mixture  of  generation,  assistance,  and  composition 

•  Reuse  ail  aspects  of  software  system  development: 

•  Requirements  Information 

•  Design  Information 

•  Source  Code 

•  Application  Architecture  made  up  of  multiple  domains: 

-  Application  Domains  (vertical) 

-  Modeling  Domains  (horizontal) 

•  Multiple  domain  specific  languages: 

-  requirements/domains  at  different  abstraction  levels 

•  transformations  within  domains 

•  refinements  between  domains 

•  History  mechanism: 

-  tactics 

•  p re-refined  subsystems 


Draco:  Key  Concepts 


Draco  embedded  the  notion  of  an  application  domain  architecture  made  up  ol  other,  often  more  general 
purpose  domains  (horizontal  domains).  These  horizontal  domains  could  be  reused  in  other  appficatian  do- 
mains.Draco  applied  rules  to  transform(restate)  specifications  within  one  level  of  ab6traction(domain)  and 
refine  specifications  into  a  lower  level  of  abstraction  (until  hopefuty  they  reached  code  oon^onems).  Dra¬ 
co  also  used  a  history  mechanism  to  capture  tactics  for  transformations/irefinements  and  resulting  re-oc¬ 
curring  subsystems. 

References: 
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Parser.  Parses  the  appScation  domain  specification. 

Prettyprinter:  Interacts  with  the  system  bidder  during  the  refinement  process. 

Draco  contains  transformation  and  refinement  rules  and  code  components. 

Domain  analyst:  Develops  domain  specific  language  This  requires  a  significant  amount  of  effort 
either  an  application  or  modeling  domain. 
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Draco:  Refinement  Process 


The  Draco  refinement  process  begins  with  specifications  only  in  the  application  domain  (e.g  Command 
Center  domain)  and  gradually  fleshes  out  the  design  by  refinjngrtranstorming  components  from  the  mod¬ 
eling  domain  (e  g.  DBMSs.  Geographical  Information  Systems.  Message  Processors...)  until  al  require¬ 
ments  are  fulfilled  by  executable  code. 
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Rose-2:  Key  Concepts 

Reuse  of  Software  Elements  (ROSE-2)  developed  by  MCC:  A  key  objwtive  in  software  design  reuse  is  to 
provide  mechanisms  that  help  the  user  select  and  adapt  design  abstractions  to  solve  software  problems. 
To  achieve  this  objective  tfie  user  should  be  presented  with  dear  requirements  and  design  alternatives 
that  he/she  can  choose  from  to  solve  problems. 

Five  Strategies: 

•  use  design  schemas  to  represent  abstract  reusable  design  solutions 

•  organize  requirements  and  design  alternatives  into  issue-based  structures  (IBIS) 

•  develop  and  customize  designs  using  the  knowledge -based  refinement  paradigm 

•  use  dependency-dkected  baddraddng  to  support  design  exploration 

•  present  multipie  design  views  to  enhance  the  reuse  and  evaluation  o(  designs. 


References: 
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Rose-2:  Key  Concepts 

Design  Schemas  contain  the  httowing  elements: 

•  basic  architecture  for  constructing  systems  of  a  general  form 

•  a  set  of  requirements  and  design  alternatives  that  specify  which  customize  Sons  can  be  applied  to 
the  design 

•  a  set  of  spedaiiaticn  rules  that  select  among  alternative  design  customtoalions 

•  a  set  of  refinement  rules  tut  perform  specific  design  customizalions 

•  a  set  of  constraints  ttiat  enforce  dependencies  between  dHterent  requirement  and  design  decisions 

•  classification  information  to  assist  in  selecting  design  schemas  trom  a  reuse  library. 

Multiple  Design  Views 

•  General  Design  Representation  (developed  by  MCC)  is  used  as  the  base  design  representation  trom 
which  the  other  design  views  can  be  dtepiayed 

•  State-transition  diagrams  and  state  charts  (to  answer  state-  and  event-oriented  questions) 

•  Real-time  structured  analysts  representations  (to  answer  data-flow  and  control-flow  oriented  ques¬ 
tions) 

•  Structural  views  (to  answer  questions  about  subsystems  and  lower-level  system  components) 


Rose-2:  Process 

Schema-based  process  of  Reusing  Design 


•  Schema  selection 

-  choose  a  design  schemafrom  a  ttwy  that  matches*  given  set  o»  user  requirements 

•  Scnema  instantiation 

-  create  an  instance  ol  a  selected  design  scheme  besed  on  the  given  user  requirements 

•  Schema  refinement 

•  supply  additional  requirements  and  design  decisions  to  further  guide  tie  refinement  end 

customization  of  the  design 

Knowledge-Based  Refinement  Paradigm 

The  selection  of  design  schemas  and  the  application  of  refinement  nies  »  semiautomabcaily  customize 
design  based  on  user  requirements  is  a  software  development  process  cafied  the  Knowledge-Based 
Refinement  Paretfigm. 
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Rose-2:  Process 


Advantages  of  Knowledge-Bases  Refinement  Paradigm: 

•  helps  to  reduce  the  size  and  complexity  of  user-supplied  software  requirements  by  supplementing 
them  with  detail  from  the  design  schemas 

•  helps  assure  that  complete  and  consistent  requirements  are  provided  by  checking  them  against  con¬ 
straints  and  esue  structures  in  the  design  schema 

•  helps  partially  automate  software  design  construction  by  applying  the  schema’s  refinement  rules 

•  helps  support  software  specification  and  design  as  parallel  and  complementary  activities  by  refining 
design  in  (fired  response  to  user-supplied  requirements 

•  helps  support  software  design  reuse  as  an  integral  part  of  the  design  process 


Design  Exploration  and 
Dependency-Directed  Backtracking 

Allow  the  user  to  supply  and  retract  different  requirements  and  design  decisions  and  observe  the  effects 
as  different  sets  of  refinement  rules  are  applied  to  customize  the  design 


Rose-2:  Issue-Based  Information  System 
Structures(IBIS) 


Faster  printing 

Cost 
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Rose-2:  Issue-Based  Information  System 
Structures(IBIS) 


•  Requirements  and  design  questions  are  formulated  as  issues 

•  Alternatives  (or  resolving  the  issues  (specific  requirements  or  design  decisions)  are  formulated  as 
positions 

•  Each  of  these  positions  can  be  supported  by,  or  objected  to,  by  arguments. 

Representational  goal  in  design  reuse  is  to  incorporate  the  IBIS  method  into  design  schemas  and  design 

reuse  mechanisms  so  that  the  following  requirements  are  met: 

•  Requirements  and  design  alternatives  are  dearly  presented  to  the  user  as  he/she  attempts  to  reuse 
and  customize  designs 

•  The  user  can  examine  Ihe  relative  benefils  and  disadvantages  of  the  various  alternatives. 

•  The  design  history  can  expict ty  be  recorded  and  examined  as  the  user  chooses  alternatives,  and 
the  design  is  subsequently  customized 


zw 
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LASSIE:  Key  Concepts 

Brooks  identified  two  problems  in  software  development  Complexify  and  Invfetoiify.  LASSIE  is  intended 
to  exploit  knowledge-representation  as  a  means  of  attacking  these  two  problems. 


•  Complexity:  Software  is  relatively  complex  compared  to  other  constructs  because  no  two 
parts  are  aHke,  and  scale-up  is  non-inear 

•  IrrvislxSty:  The  structure  of  software,  unlike  buildings  or  automobiles,  is  hidden  and  dMicult 
to  visualize.  Execution  behavior  is  the  way  we  generally  get  behavioral  data 

The  developer's  burden  is  to  determine  whether  something  has  been  done  before  and  how  to  make  it  con- 
form  to  the  architecture.  But: 

•  Invisibilty  leads  to  violations  of  the  architecture. 

•  Architecture  violations  create  more  irregularities,  therefore  more  complexity. 

•  Increased  complexity  intensifies  invistoity.  And  so  on .. . 

This  also  hampers  reuse  and  tostere  wasteful  raimplemenlationB,  which  in  turn  exacerbate  nvteNity  and 
complexity  and  erode  integrity. 

invisibility  is  also  manifested  by  a  ‘dacovery  phenomma:* 

•  what  a  developer  or  maintainer  must  do  to  prepare  for  the  actual  task 

•  takes  approximately  50%  ot  all  developer's  time 

•  is  a  trai  of  inquiries  to  gain  understanding  of  the  system  at  hand. 

•  Visual  dteplays  are  not  effective;  even  graphs  don’t  simplfy  things  much.  Documents  are 
rarely  up-to-date  and  correct  and  complete  and  available  and  oriented  towards  discovery. 
Knowledge  largely  resides  in  experts  who  may  not  be  available  or  willing  ;  may  have  to  re¬ 
establish  context;  may  not  explain  well. 
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LaSSlE  Key  Concepts 
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LaSSlE:  Key  Concepts 
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LaSSIE:  Key  Concepts 


Knowledge  Base  .  Emphasis  is  on  capturing  the  semantics  ol  the  actions  and  objects  at  the  architecture. 
Support  is  provided  for  complex  questions  involving  architectural,  conceptual  and  code  views  without 
knowing  structure  oi  Knowledge  Base. 


User  Interface:  Provides  easy  access  ai  a  conceptual  level  via  a  window/mouse  interface.  Provides  X3uery 
by  Reformulation'  (Patel-Schneider,  Brachman  &  Levesque). 


Knowledge  Representation:  Ftame-b8sed  system  with  inheritance,  which  otters  economy  of 
representation  and  semantic  integrity.  Retrieval  "hits"  ere  instances  of  the  frames  subsumed  by  the  query. 


Example:  System  recognizes  that  merge-action  is  a  connect-action  based  on  the  descriptions  ot 
each.  It  also  realizes  from  the  description  (not  shown  here)  of  Attd-Button-Push  that  this  is  an  action 
by  an  attendant,  which  is  defined  to  be  a  spedafization  of  user.  The  Argon-lfce  user  interface  displays 
the  retrieved  imfviduais,  from  which  tie  user  can  sated  one  lor  detafled  display,  with  all  its  slots  and  filers, 
each  of  which  itself  can  be  selected  for  further  deplay. 


Limitations:  Action-based  representation  does  not  help  the  developer  establish  the  oontexts  in  which  the 
actions  are  performed  -  no  map  of  the  territory.  Plan-oriented  questions  like: ‘Why  is  this  operation  being 
performed?"  are  nor  supported.  Knowledge  acquisition  is  essentially  manual. 
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LaSSIE:  Related  Tools  - CODE-BASE 


Complementary  to  LaSSIE:  LaSSIE  supported  semantic-based  dtecovery  in  a  hand-coded  domain 
modei.Qoai  is  to  extend  conceptual  modal  to  Incorporate  a  code  modal  and  provide  meaningful  inks 
between  them.  CODE-BASF  represents  code-level  information  (at  the  level  of  a  conetuct  such  as  a 
procedure,  (unction  or  declaration)  which  is  automeiicatty  acquired,  thus  guaranteeing  synchronization  of 
KB  with  the  code.  The  user  interface  allows  posing  of  specific  queries  as  weB  as  "hypertext*  style  traversal. 
Thus  we  see  a  reverse  engineering  type  tool  supporting  a  reuse  tod. 

CODE-BASE :  example: 

*  Upper-Left  Panel :  Browse  the  concept  hierarchy 

*  Upper-Right  Panel :  Examine  an  individual  concept 


•  Middle  Panel :  Where  CODE-BASE  queries  are  entered 


Lower-Left  Panel :  Display  instances  which  match  the  query 


Lower-Right  Panel :  Display  a  selected  instance 
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LaSSIE:  Related  Tools  -  Design  Assistant 


LaSSlE:  Related  Tools  -  Design  Assistant 


•  Need  to  caphmtfwtaMorewNch  knot  documented  and  remains  accessible  only  tfvouQh  hunan 
experts. 

To  manage  such  knowledge  with  automation  we  must  deal  with:  tiffieutty  of  acquisition,  representa¬ 
tion  end  aocessfciity,  and  mahitainence  of  design  knowledge 

•  Canl  assume  a  lump  sumf  single  occurrence  capture  of  aB  the  Imowledge.  Need  facKtees  to  capture 
elaboration  and  evohifion  of  design.  Need  tacSfiee  to  caplue  new  knowledge  arising  torn  normal 
design  and  review  activities. 

*  Taxonomy  of  design  problems  with  associated  advice  Heme  which:  removes  redundancy  and  tacS- 
tales  an  advice  exception  (i.e.,  override)  mechanism.  KB  to  accessed  by  a  design  assistant  progrem 
which  manages  the  systenVuser  dialog. 

*  Maintenance  via  the  incorporation  o<  design  advice  into  the  design, 
so  it  is  also  subject  to  the  normal  organizational  review  process. 
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KAPTUR:  Key  Concepts 


Tool  Supported  Methodology  Developed  by  CTA, 
me.  wMh  NASA  Sponsorship 

Advocates  a  Case-Based  Reasoning  Approach  to 
Domain  Analysts  (La.  Cats  Bated  Domain 
Analysis)  Winch  Combines: 

•  object-oriented  modeling, 
clan,  objects 

■  iimnim 

•  methods  (services,  functions) 

-  variables  (attributes) 


-  fsetura  modeltng,  and 

-  extension  of  SB  FODA  fay  Including  both 
vtstote  and  non-vlslble  user  features. 

-  caa»  based  reasoning 

Captures  (hence  KAPTUR)  Domain  Products, 
Legacy  Systems,  Features,  Design  Tradeoffs 
■no  irmiotme 

Follows  a  Supply  Side  <->  Demand-Side  Cycle  to 
Domain  Analysis  and  Systems  Analysis 

Supports  Various  Architectural  Perspectives 


_ 

KAPTUR  was  developed  by  CTA  Incorporated  under  NASA  sponsorship. 

KAPTUR  is  a  tod  tttal  is  used  in  conjunction  wHh  an  entire  domain  analysis  process  that  begins  with  iden¬ 
tifying  and  scoping  a  domain,  capturing  and  analyzing  domain  mtormation,  creating  a  validated  domain 
model,  and  using  the  Knowledge  captured  and  modeled  to  generate  new  systems  in  the  domain  using  the 

knowledge  gained  from  the  legacy  systems  in  the  domain.  KAPTUR  is  the  tool  used  to  organize  and  struc¬ 
ture  the  information  relative  to  the  domain,  as  well  as  document  decisions  made  in  the  development  ol  do¬ 
main  systems. 

The  supply  side  of  the  KAPTUR  process  (and  model)  involves  the  accumulation  of  domain  Knowledge,  or¬ 
ganization  of  that  Knowledge,  and  Knowledge  placement  in  the  KAPTUR  tool.  The  supply  side  person  is 
Ore  a  domain  manager,  a  domain  owner,  or  a  domain  developer -an  expert  in  the  domain  and  the  person 
who  creates  the  representations  of  the  legacy  systems  in  the  domain.  This  person  takes  the  perspective 
that  components  need  to  be  reused  and  can  cSstingursh  the  features  or  characteristics  that  make  a  com¬ 
ponent  reusable.  The  demand  side  of  the  KAPTUR  process  (and  model)  involves  the  use  ol  domain  knowl¬ 
edge  as  it  applies  to  a  new  system. 


References 

CTA  Incorporated 
61 16  Exdcuttv*  Boulevard 
RockvSa,  MO  20852 
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KAPTUR:  Tool  Functionality  and  Representations 


mm#*  *0 


Tool  has  tflract  support  for  capturing 
trads-ofts  and  rationale  for. 

-  Operational  Faatuiaa 

•  Functions 

•  Performance 

-  Development  Methodology 

•  Deetgn 

•  Implementation 

Alternative  Architectural  Views  allow 
dHferent  perspectives  of  system  via: 

-  Enttty-fMationsNp  Diagram 

•  Data  How  Diagram 

-  Object  Communication  Diagram 

•  Stbnulue-Response  Diagram 

-  State  Transition  Diagram 

•  Assembly  Diagram 

•  Classification  Diagram 
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Descriptive  information  is  avalabie  for  each  architecture  and  annotations  (descriptive  information)  are 
available  for  each  element  in  an  architecture  view.  Associated  with  each  architecture  is  a  set  of  features 
and  with  each  feature  is  information  deating  with  the  decision  that  feature  represents,  tie  trade-off  asso- 
dated  with  the  decision,  and  rationale  tor  tie  decision  made.  Any  feature  may  or  may  not  be  present  in 
any  ot  the  architectures.  To  the  exient  that  a  feature  is  in  one  architecture  and  not  in  another  indicates  al¬ 
ternative  implementations  that  a  user  may  need  to  consider.  Based  on  tie  presence  or  absence  of  a  fea¬ 
ture.  the  user  may  need  to  go  and  look  at  an  alternative  architecture,  again  looking  at  the  features, 
decisions,  trade-offs,  and  rationale  information. 

KAPTUR  is  a  tool  used  to  represent  software  architectures  in  support  of  object-oriented  modelng.  KAP¬ 
TUR  has  several  ways  in  which  to  represent  the  objects  analyzed.  There  are  various  architecture  views 
(or  perspectives)  currently  available  in  KAPTUR. 
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UNAS:  Key  Concepts 


*  Universal  Network  Architecture  Services  (UNAS) 
—  developed  by  TRW 

•  A  Procees-besed,  Asynchronous,  Message- 
driven  Language  Framework  for  Rapidly 

Developing  Distributed  Applications 

-  A  Collection  of  integrated  Tools  to  Support 
tw  Development  and  Management  of 
Distributed  Applications 

-  A  Software  Architectural  Design  PamSgm 


Standard,  Integrated  Development  Environment 
-  Compilers,  CASE  Tools,  Debuggers 


Softwars/Systam  First  Mentality 
•  Prompt—  tht  tftvilopniint  of  thi  “logictT 
— cMt—fluvi  first*  wMdi  It  taur  ntsppsd  to 
ths  “physio T  irehilictoitifcWliclufii 
sf—nts  mi  stfocstsd  to  huttwin) 


btayfasw  !*«». rimnme n« 

ounaiiU]  inwgimo  nuniiiw  cjvyuuiniioiii 

-  Runtime  and  off-line  analysers,  networic 
resource  management,  runtime  Ibreries 
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At  it's  core,  UNAS  can  simply  be  defined  as  a  high  level  language  tor  buikfing  software  architectures  This 
language  is  targeted  for  applications  (potentialy  detributed  and  potendaly  heterogenous)  baaed  on  a 
message  driven  paradigm.  However,  in  addition  to  being  a  language  there  exists  a  highly  integrated  col¬ 
lection  o!  tools  and  services  which  support  the  development  of  UNAS  dstAuled  applications  and  die  runt¬ 
ime  management  of  those  applications.  These  tods  and  language,  together,  define  UNAS's  architectural 
design  paradigm  which  is  supported  by  architectural  representation,  rules  for  assembling  elements  of 
UNAS  elements  and  toots  to  enforce  that  pwacBgm. 

UNAS  development  environment  permits  the  architect  to  buit  the  system  first  without  actualy  being  con¬ 
cerned  with  the  underlying  physical  implementation  or  hardware.  This  TogtcaT  architecture  can  be  defined 
in  terms  including  performance,  structure  and  control  &  data  flow  and  then  executed  to  establish  metrics 
with  which  to  perform  comparative  analysis  against  expected  and  actual  results.  Architectural  elements 
can  be  assigned  and  alocated  to  the  target  hardware  environment,  thus  instantiating  the  “physical-  archi¬ 
tecture  from  the  logicar. 

References 

UNAS  Training  Ctaaa,  July  7-9. 1993 

TRW  8y*ta<na  Enginaartng  4  Pedopiranl  DftMon 

otensn 

Canon,  CA 
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UNAS:  Tool  Functionality 

•  UNAS: 

•  (WlnM  basic  architectural 
elements  and  rotos  lor  their 
Interconnections 

•  provides  messaging  between  and 
control  &  management  of  Mom 
elements 


•  SALE  —  trontsnd: 

(UNAS  CASE  Tool  Option) 

-  QLIItor  bi^anfl  UNAS  dtotrtfautsd 

'  En*°fc**  UNAS  software 
architecture  concepts — 
nMonoMpo  and  rotos 

•  SALE  —  backend: 

•  AM  cod*  generation  utMilng 
underlying  UNAS  sendees 

-  Load  and  performance  models 
tram  bahavtoral  Input  to  SALE 

*  oynwri  oooum#nc8ti0fi 
generated  from  toxtuoi  and 
graphical  Input  to  SALE 


UNAS'#  CASE  Tool  option,  SALE — System  Architects  Lifecycle  Environment  enforces  UNAS*s  method¬ 
ology  lor  buM  software  architectures  tram  UNAS  elements.  SALE*  graphical  user  interface  stows  tie  ar¬ 
chitect  to  instantiate  architectural  elements  and  Mter-oonnect  and  group  them  to  form  larger  components 
in  a  consistent  mamor.  As  the  architecture  is  created,  SALE*  accepts  expected  or  required  performance 
mottles  and  design  oonsiderationB  d  tasks  and  processes  in  the  system. 

As  a  back-end  tod.  SALE  win  generate  complete  compiable  source  code  which  utilize  underlying  UNAS 
inter-task  communication  (ITC)  and  generic  application  controls  (GAC)  services.  Once  compiled,  the  ap¬ 
plication  built  can  be  executed  as  a  skeleton  which  wit  exhibit  performance  behavior  as  presented  to  ihe 
tod.  SALE  w*  automaticady  generate  design  documentation  which  describes  both  mission-independent 
and  mission-dependent  (dial  which  was  entered  into  the  CASE  Tod)  portions  of  the  application. 

The  UNAS  massage  product  provides  the  basic  services  tor  Inter  Task  Communication  (ITC)  capabikty 
known  as  ITC  services  and  automatic  heterogeneous  data  translation.  Data  structures  written  in  Ada 
source  are  converted  to  meta-message  format  via  UNAS  off-line  message  registration  tools.  The  meta¬ 
message  formal  iB  the  mechanism  that  permits  data  conversion  between  heterogeneous  network  nodes. 
Further,  ITC  services  provides  that  Ada  package  generic  to  ensure  Ada's  strong  type  cohesion  between 
the  distributed  process  which  write  and  read  passed  messages. 

Other  services  ollTC  include  error  reporting  and  propagation,  task  creation,  interactive  network  manage¬ 
ment,  SNMP  interlace  to  network  management,  and  message  interjection  and  recording. 

UNAS’6  Generic  Application  Control  (GAC)  is  a  higher  levet  of  abstraction  d  the  services  provided  by  ITC. 
Pragmaficaly,  GAC  removes  the  application  developer  from  many  d  the  ‘quirks'  and  detais  of  the  ITC 
layer  as  wel  as  adding  buffered  I/O  to  network  message  passing,  message  queuing,  logical  separation  d 
nodes,  processes  and  sockets  from  their  physical  implementation,  and  built-in  performance  and  utilization. 
Additionally,  exception  handling,  error  reporting  and  logging  is  greatly  enhanced  and  abstracted  in  the 
GAC  layer. 
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UNAS:  Representations 


(JNAS  Architecture  Paradigm 
•  Basic  elements: 

/  X  Tasks  exchanging  messages 
i-dipP  Messages  are  exchanged  over  interconnected  sockets 
o  A  Socket  is  a  names  source/destination  associated  with  a  task 
— Connections  are  paths  between  sockets  controlling  message  flow 
j  1  Tasks  are  organized  into  Processes  for  control  and  re-configuration 
1  |  Processes  are  combined  into  Groups  for  operational  uniqueness 
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These  are  the  most  baste  architectural  elements  that  can  be  used  to  buld  a  UNAS  application.  Processes 
are  made  up  of  one  or  more  tasks  which  communicate  over  one  or  more  sockets  connected  to  other  tasks 
(or  itself  in  the  case  ol  timer  sockets).  Messages  are  used  to  communicate  data  over  interconnected  sock¬ 
ets.  Sockets  can  be  connected  together  via  connections  (or  circuits  in  earter  UNAS  terminology)  and  can 
be  either  read-only,  write-only,  or  read-write.  The  figure  below  shows  an  example  ol  a  simple  UNAS  appli¬ 
cations  in  terms  of  these  elements. 


In  the  above  figure,  the  task  “Federal_Express“,  communicates  via  a  “Write_Sockel“  with  another  task 
called  “Customer*.  The  message  that  is  passed  from  the  first  task  to  the  second  task  can  only  be  of  type 
“Federal  Express  Message’.  In  this  example,  either  task  can  belong  to  a  different  process,  or  they  could 
be  two  tasks  in  the  same  process. 
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Technology  Book:  Key  Concepts 


Technology  Book:  Key  Concepts 


The  toots  presented  in  this  section  are  based  on  the  approach  used  at  Schtumberger.  Design  evolution  and 
maintenance  are  the  dominant  activities  in  many  software  development  organizations.  Thus,  the  reuse  of 
analyses  and  designs  «  ol  greater  benefit  than  the  reuse  ot  software.  To  obtain  this  benefit  the  engineering 
environment  should  provide  a  Domain-specific  information  workspace  and  efferent  access  to  the  best 
information  avaiable  in  the  organization.  The  approach  is: 

Domain  analysis  to  consolidate  critical  analysis  and  design  information  for  product  families. 


Representation  of  reusable  information  in  structured  form  via  Technology  Books’. 


1 Graft-Host  method  for  reusing  design  information  and  managing  databases  of  constraints  in  a 
systematic  and  reSabie  way. 

Ralarancaa:  QuMaimo  Arango.  Erie  Sctnan  and  RobanPanangM 
A  Pioeaaa  tor  Conaordatng  and  Rauaing  Daalgn  Knowladga 
Piocaadngao trim  ism  mn/rmtontl  ConMranca  on  SoUwm  Engriaartnp 
May  17-21. 1983  Battnora.  MO.  pp.  231-242. 

QuWarmo  Arango.  Erie  Semen.  Retail  Patange  and  Joaian  HoaMna 
The  Qiaft-Hoa  Mono  tor  DMignCiMna* 

Pioa—anototTm  iSrii  rnraffiarisnalGoflriranca  on  Sorturara  Engtnaartnp 
May  17-21. 1993  Baunora.  MO.  pp.  243-254 

QuMwmo  Arango.  Erie  Schoan  and  Retail  Penang* 

DeaignaaEvoiuUonandReuee 

PmettOngt  atom  sieond  rnrarmBonM  MMcaftop  on  SDriwwa  flaoaaWBy 
Marc*  24-29. 1993  Lucca.  Uty 
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Technology  Book  Use: 
Finding  an  Algorithm 
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Technology  Book  Use: 
Finding  an  Algorithm 


In  (1)  the  user  finds  there  are  three  choices  of  algorithm  tor  computing  toe  CRC  using  the  taxonomc 
relationship. 

Then  in  (2)  she  folkMs  an  analysis  of  their  space  and  time  properties. 

She  identifies  multiple  combinations  of  generator  polynomials  and  algorithms  in  (3). 

Finding  that  she  must  use  CRC-16  to  maintain  backwards  compati bitty,  inspects  the  CRC-16  Pattern 
Algorithm  in  (4). 

She  finds  in  (5)  the  required  polynomial  coefficients  via  a  uses  relationship. 

Finally,  she  inspects  a  mathematical  description  of  the  algorithm  in  (6)  via  a  documentation  link. 
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Technology  Book  Use: 
Finding  an  Algorithm  Implementation 


2M 


Technology  Book  Use  2: 
Finding  an  Algorithm  Implementation 


User  selects  the  algorithm  in  (1). 

The  implementation  relation  graph  (2)  shows  there  are  three  implementations  of  the  CRC-16  pattern 
algorithm. 

Designer  selects  a  C-tanguage  implementation  in  (3)  and  browses  the  source  code. 

She  also  views  the  detailed  documentation  in  (4)  tor  the  chosen  implementation. 


Technology  Book:  Tools 


Technology  Book :  Tools 

The  representation  Is  a  compromise  between  usability  and  formality: 

•  Semantic  Tags:  issue,  definition,  assumption,  imported  constraint,  exported  constraint, 
position,  design  decision,  unresolved,  result 

•  Syntactic  Tags:  authors,  headings,  equations,  enumerations. 

-  Information  Is  stored  In  typed  nodes  and  relations  between  them. 

•  Information  nodes  we  organised  Into  taxonomies  by  type: 

domain  entities,  project  entities,  work  products,  resources,  statements,  analyses. 

•  Relations  Include :  history,  taxonomy,  derivation,  aggregation,  use,  justification, 
interconnection,  ownership  -  as  determined  by  domain. 

•  RADIO  Environment  (with  Motif-based  GUI)  includes:  Object  oriented  DBMS,  DOLL  (ModeKng  Lan¬ 
guage),  and  Document  Preparation. 

•  RADIO:  provides  Browser  /  Edita  fa:  depicting  book  contents,  navigation,  and  updating. 

•  DOLL:  emphasizes  descriptiveness  and  runtime  flexibility,  not  runtime  speed  a  storage  minimiza¬ 
tion.  Nonetheless  it  provides  subsecond  response  time.lnformal  elements  (text  pictures,  tables, 
equations)  are  stored  as  Framemaker  attachments  to  DOLL  objects. 
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Technology  Book:  Graft-Host  Method 


Design 


Reconcile 


Reconcile 


Reconcile 


Target  in  Host 
Analysis 


Design 


Implementation 


Technology  Book:  Graft-Host  Method 


Helps  make  design  constraint  management  a  systematic  and  reliable  process. 
Host :  System  to  be  changed. 


Target :  Subset  of  tbe  Host  affected  by  the  change. 

Cntft ;  Proposed  substitution  tor  the  target 

•  Reduces  risk  in  change  by  providing  guidance  tor  developing  change  plans. 

•  Reduces  need  (via  technology  books)  lor  designers  to  rediscover  design  rationales. 

•  Fewer  design  iterations;  more  errors  caught  more  early. 


Shorter  training  times  (or  engineers  and  maintainors. 
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ULEANNA:  Key  Concepts 


ULEANNA:  Key  Concepts 


LILEAnna  is  a  Library  Interconnect  Language  Extended  with  Annexed  Ada,  which  is  intended  to  sup¬ 
port  high  level  abstraction,  composition  and  reuse  o(  Ada  Software.  LILEANNA  supports  the  design 
of  parameterized  components  and  software  architectures. 

The  language  was  designed  to  alow  certain  automated  analyses  based  on  formal  specification  of 
preconditions  (using  the  Anna  toolset);  Automated  selections,  composition,  tailoring  and  instantiation 
of  Ada  code  from  LILEAnna  specification  and  pre-existing  Ada  code. 

LtL  and  Anna  were  pre-existing  languages  that  have  been  refined  and  merged. 

-  UL  is  language  for  designing,  structuring,  composing,  and  generating  software  systems. 

-  Anna  is  a  language  extension  of  Ada  to  include  taciRties  for  formally  specifying  the  intended 

behavior  of  Ada  programs.  It  is  designed  to  meet  a  perceived  need  to  augment  Ada  with 
precise  machine- processable  annotations  so  that  wel-estabished  formal  methods  of 
specification  and  documentation  can  be  applied  to  Ada  programs. 

References:  Tracz,  W.  *A  conceptual  model  for  mega  programming"  ACM  SIGSOFT  SEN  July  1991 

Tracz,  W.,  "ULEANNA:  A  Parameterized  Programming  Language’  in  Proceedings  of  the  Second  In¬ 
ternational  Workshop  on  Software  Reusability,  March  24-26, 1993,  Lucca,  Italy 

Goguen  'Reusing  and  Interconnecting  Software  Components*  in  Domain  Analysis  and  Software  sys¬ 
tem  Modeling  Prieto- Diaz  and  Arango 

Luckham  and  von  Henke  'An  overview  of  Anna  a  Specification  Language*  fa  Ada  *  IEEE  Software 
March  1985 


ULEANNA:  Key  Concepts 

•  ULEANNA  provides  mechanisms  to  specify  abstraction  and  composition  o(  Ada  packaoes.lt  has  the 
Look-and-Feel  of  a  language  that  extends  the  existing  Ada  packages  specifications,  instantiations 

and  dependency  mechentems.  ULEAima  extends  Ada  by  introducing  two  entities:  theories  and 
views,  and  enhancing  a  third,  package  specifications.  It  introduces  [generic]  theories,  which  provide 
a  formal  specification  of  hncfionafity .  It  also  introduces  [generic]  packages  as  abstraction  for  Ada 
[generic]  packages,  which  can  serve  as  an  abstraction  tor  mitipie  Ada  packages  or  implementation 

•  Supports  Architecture  specification  aid  construction  of  a  executable  Ada  application  with  two  fea¬ 
tures  VIEWS  and  MAKES. 

•  VIEWS  aDovs  users  to  specify  how  generic  parameters,  exported  services,  and  (tor  LJLEAnna 
packages)  imported  services  are  bouid  to  (provide  by)  other  ULEAma  theories.  ULJEAnna 
packages,  Ada  packages,  and  the  objects  exported  by  them. 

•  MAKES  slows  users  to  specify  how  Ada  packages  can  be  composed  and  instantiated  to  form 
other  Ada  packages,  where  VIEWS  can  be  ueed  to  reftaed  and  control  tiis  process. 

•  Both  VIEWS  and  MAKES  alow  parial  bindings,  which  H  carried  through  the  MAKES  process  results 
in  Ada  generic  packages. 

•  Existing  packages  may  be  manipulated  through  packages  expressions  specify  the  instantiation,  ag¬ 
gregation,  renaming,  additions,  elimination  or  nepiaoement  of  operations,  types  or  exceptions. 

•  Provides  support  tor  version  and  configuration  management 

•  Provides  multipie  controlled  inheritance 

•  Supports  the  structuring  and  composition  of  software  modules  from  existing  modules. 
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ULEANNA:  Tools 


ULEANNA  can  be  programmed  in  directly  or  used  with  a  variety  of  front  end  toots.  The  ULEANNA 
translator  is  part  of  the  IBM  OSSA  Avionics  Domain  Application  Generation  Environment.  A  graphical 
composition  front  end  tool  has  also  been  proposed. 


\Jtaplde:  Key  Concepts 

•  Executable  architecture  definition  language. 

•  Mo  da  la  ttmo  eenaMve,  concurrent  and 
dtotrtbuted  hardware  end  eoflweie  systems. 

•  iiRapIde  Feature*  Include 
-  event  pattern* 


■  architecture* 

-  mapping* 

Tool  Supported: 

-  CW. -Common  Prototyping  Language  front- 
end  compber  which  tranaMte  pHapld* 
aource  code  Into  Ada 

-  IRS  -  Mustreted  RurMbns  System  tor  the 
viewing  and  printing  of  psrttslly  ordered 
event  tracee  generated  by  pRaplde 

computations. 

•  POB-ParUaMy  Ordered  event  trace  Browser 
for  the  viewing  of  tiRapide  computations  a* 
they  occur. 


\Jtapide:  Key  Concepts 

Event  patterns  are  expressions  that  define  sets  of  events  and  their  dependency  and  timing  relationships. 
An  event  signifies  an  activity  during  system  execution.  Event  patterns  contain  information  such  as  threads 
of  control,  data  values,  time  interval;  modelled  as  a  tuple  of  values.  Execution  of  a  distributed  system  is 
modelled  as  a  partially  ordered  set  of  events,  caked  a  poser,  based  on  causality  or  timing  relations. 

An  interface  gives  an  external  view  of  the  behavior  of  a  type  of  component  and  defines  how  components 
of  its  type  react  to  events  by  changing  state  and  generating  new  events.  Members  of  a  component  type 
are  caked  objects. 

Architectures  define  the  flow  of  events  between  interfaces.  An  architecture  consists  of  a  set  of  components 
(objects  of  some  interlace  types)  and  a  set  of  rules.  These  define  how  the  components  communicate  by 
sending  each  other  events  or  calling  each  other's  functions.  Communication  rules  are  defined  using  event 
patterns. 

Mappings  define  how  architectures  are  related.  One  can  then  define  how  events  in  one  system  correspond 
to  events  in  another.  In  die  domain  of  design  hierarchies  refinement  map6  serve  to  express  complex  low 
level  simulations  as  behaviors  of  a  higher  level.  The  mapped  behavior  is  much  smaller  and  simpler. 

References 

David  C.  Luddiam  and  James  VerapRapide:  An  Executable  Architecture  Definition  Language  April  7, 1993 
David  C.  Luddism  and  Jamee  Vera  Event-Baaed  Concept*  and  Language  for  System  Architecture  March  16, 1993 
Rapide-0.2  Language  and  Tool-Set  Overview  Doug  Bryan  February,  1992 
Theee  and  related  papers  are  available  via  anonymous  tip  to  anna.stan1ord.edu.  in  /pubfRapide 

no 


\iRaplde:  Example 


•  MySpeaker,  CDPtayer  and  TapaPtayar  ara 
componanu. 

-  Components  can  teoelvo  Input  events, 
generate  output  avants  (altadad 
rag  tons)  to  communlcsts  with  the 
external  environment 

■  Dirac  tad  polygona  Indlcata  Intarnal 
avanta. 


•  During  execution,  play  cauaad  a  linear 
sequence  of  avanta,  aacti  dapanding  on 
the  previous,  resulting  In  noise. 


•  Stop  cauaad  a  Hnaar  aaquanca  of  avanta 
raaultlng  In  silence. 


•  There  la  no  dapandancy  between  any 
avant  In  tha  first  aaquanca  and  any  avant 
In  tha  aacond  aaquanca. 


•  Given  ttila  particular  axacutlon  poaat,  tha 
system  usar  Invoiced  Ptay  before  Slop. 
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[ iRapide :  Example 


In  the  example,  paths  Item  AudioOut  events  to  Audioin  event  indfcate  communication  tram  CDPlayer 
and  TapePlayer  to  My  Speaker.  So,  fitey  complete  the  definition  of  this  architecture  -  since  an  architec¬ 
ture  defines  haw  components  communicate  by  means  of  events. 

Note  that  tor  this  example,  there  are  no  timing  constraints  between  any  of  the  other  events,  which  means 
there  is  a  possible  design  fiaw:  A  user  could  invoke  Play  then  Stop,  but  still  hear  noise  because  the  events 
depending  upon  Stop  could  overtake  Hie  events  depending  upon  Play. 

Using  mapped  behavior  (from  complex  low-level  systems  to  simpler  high-level  systems)  yields  these  ben¬ 
efits: 

•  Facilitates  understanding.  (One  application  of  mappings  reduced  the  event  space  from  8073 
to  5.) 

•  The  formal  constraints  of  high  level  architectures  which  capture  design  requirements  can  be 
automatically  checked  when  tow -level  simulations  are  "mapped  up*. 

•  Errors  in  the  mapped  behavior  can  be  traced  back. 
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Architecture  Based  Reuse  Tools:  Summary 


Features  found  in  tools: 

•  easy  access  to  large  amounts  ot  Knowledge 

-  problem  space  -domain  specific  semantics 

-  solution  space  -  architecture 

•  assistance  •  person  In  the  loop 

-  method  accompanies  tool 

•  rationales  and  trade-offs 

-  composition  -  components  and  horizontal  domains 

-  language  and  graphics  oriented 

-  some  tools  biased  toward  an  architectural  style 

-  requirements,  architecture,  detailed  design,  code  intermingled 

-  evaluation  through  automated  analysis  and  simulation 

-  source  code  generation 
Future?: 

•  Integrated  tool  sets 

•  knowledge  acquisition  support 

-  cooperative  design 
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Architecture  Based  Reuse  Tools 


II  is  dffiaiit  to  draw  a  coherent  picture  from  Mb  or  any  set  of  tools  bf  ause  architecture  based  reuse  is  stil 
an  emerging  area  but  some  oi  the  trends  are  dear.  One  major  Irena  e  Ihe  capture  of  huge  amounts  of 
problem  space  (domain  apecilc  context)  and  solution  apace  knowledge  in  organization  wide  knowledge 
bases  which  have  user  interlaces  designed  tor  easy  browsing.  They  also  provide  some  mtetiigent 
assistance  to  help  apply  that  knowledge.  There  is  stH  a  tension  between  tormal  and  informal 
repreaentationB.  Another  major  trend  is  toe  emphasis  on  capturing  rationalee.  These  rationales  provide 
dues  Fiat  promote  contormance  to  an  architecture. 


Some  tools  clearly  work  on  the  assumption  of  an  underlying  architecture  style.  Others  allow  the  user  to 
follow  their  mm  architecture  style.  The  tools  do  nol  tend  to  Kmrt  themselves  just  to  representing 
architecture.  They  often  include  detailed  design,  requirements  and  code. 


It  is  difftcUt  to  predict  winning  trends.  Tool  integration  w#  continue  to  be  a  major  goal.  Tools  that  require  a 
lot  ot  knowledge  need  to  support  acquisition  and  storage.  Since  designers  do  not  woifc  alone  on  targe 
systems  we  should  see  increasing  support  tor  cooperative  colaboration. 
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Roadmap  for  this  Session 


S3* 


CARDS  Scientific 

CARDS  Engineering 

CARDS  T ranaffloivto-Practice 


•  Architecture  Task  Fore* 

•  0rgani2*tk>Ml  Domain  Modeling: 
Domain  o(  Software  Architecture 
Representation 

•  Component  QuaBflcatton 

•  System  Composition 


•Handbooks 
•  Franchlalnfl 
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Presentation  Overview 


During  the  portion  of  the  seminar,  the  CARDS  approach  to  Domain  Engineering  activities  as  they  relate  to 
software  architectures  wll  be  discussed. 

CARDS  Phase  1  focused  on  the  mechanics  of  Domain  Engineering  activities,  making  sure  the  infrastruc¬ 
ture  hardware  and  software  and  library  modeling  processes  (unction  correctly. 

During  Phase  2,  CARDS  focused  on  refining  the  processes  of  and  developing  prototype  tools  for  domain 
specific  component  quatification  and  system  composition. 

For  Phase  3.  the  CARDS  locus  is  on  architectures.  An  Architecture  T ask  Force  (ATF)  was  constituted  with 
the  goal  of  determining  the  best  processes  for  capturing  and  representing  architecture  information  jn  the 
library  framework. 

Throughout  ail  the  phases,  CARDS  has  documented  and  transferred  ttte  information  through  its  formal  de¬ 
liverables  and  franchising  efforts. 


Architecture  Task  Force  Context  &  Goals 

ATF  Goals 

•  Formalin  the  CARDS  modeling 
approach  for  software  architec¬ 
tures 

-  facilitate  franchise 
implementations 

-  basis  for  reuse  tools 

•  Gather  and  synthesize  informa¬ 
tion  for: 

-  Reuse  Adoption  Handbooks 

-  Evaluation  of  current 
technologies  (e.g.  UNAS, 
KAPTUR,  etc.) 

-  Architecture  Seminar  & 
Workshop 


_ 

Architecture  Task  Force  Context  &  Goals 

CARDS  has:  1 )  Basic  technology,  model  base  with  Afferent  views  of  the  knowledge;  toots  (e  g.  browser, 
composer,  quaffier)  that  work  off  the  base  and  2)  Process  tor  certifying  components  for  a  domain  (see  later 
slides)  and  modefing  the  qualification  information. 

CARDS  needs:  1)  'Good'  Software  Architecture  Representation  (SAR),  and  2)  Semantics  for  the  integra¬ 
tion  of  multiple  architecture  views. 

Considerations: 

•  What  abstractions  are  needed  to  support: 

•  automated  component  qualification  and 

•  system  composition? 

•  What  information,  technology  is  needed  to  support  refinement  and  composition  processes; 
system  design  and  analysis  processes;  procurement,  etc? 

•  What  technologies  are  avalable  for  architecture-centric  reuse? 

-  how  do  cStterenl  technologies  fit?" 

•  what  are  the  invariants  which  allow  representation  and  tooling  diversity? 

•  What  approach  should  CARDS  adopt  to 

•  support  systematic  modeling  without  requiring  an  advanced  degree  in  Al? 

•  provide  a  conventional,  non-AI  interface  to  the  CARDS  model  base? 


Approach:  ODM  for  Software  Architecture  Representations 

DA  praoMt  (Tatorad  OOM) 
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Approach:  ODM  for  Software  Architecture  Representations 

Organization  Domain  Modeling  (OOM)  is  a  STARS  Domain  Engineering  methodology.  ODM  is  based  on  col¬ 
laborative,  team-based  modeling  involving  all  the' “Stakeholders'  of  the  domain.  ODM  provides  the  abiity  to  map 
points  of  commonality  and  dfflerence  wfthout  trying  to  work  or  resolve  alternatives  too  rapkly.  There  is  method¬ 
ology  support  to  model  alternative  *views*  o(  the  same  intomiation.  OOM  views  the  domain  as  the  defined  scope 
oi  reuse. 

OOM  has  two  distinct  phases,  descriptive  modeling  in  which  commonalities  and  deferences  are  modeled,  and 
a  prescriptive  phase  where  the  modeling  represents  decisions  and  commitments  to  functionality  to  be  supported 
and  expresses  the  range  of  variability 

Note:  ODM  presumes  the  definition  of  domain  put  forward  by  Anango  &  Prieto  Diaz  that  says:  “A  body  of  infor¬ 
mation  e  considered  a  probtem  domain  if: 

•  Deep  or  comprehensive  relationships  are  town  or  suspected  with  respect  to  some  class  oi 
problems 

•  There  is  a  community  that  has  a  stake  (that  is,  stakeholders)  in  solving  the  problems 

•  The  community  seeks  software  intensive  solutions  to  these  problems;  and 

•  The  community  has  access  to  knowledge  that  can  be  appfied  to  solving  problems’ 

•  And  Software  Architectures  fits  every  one  of  tieir  criteria. 

References 

Mark  Simos,  Omanizational  Domain  Modeling.  STARS  Technical  Report,  Unisys  Corporation. 

Guillermo  Arango,  Prieto- Diaz,  R.,  ‘Domain  Analysis  Concepts  and  Research  Directions  *  in  Domain  Analysis 
and  Systems  Modeling,  IEEE  Computer  Society  Press,  1991 .  ISBN  0-8186-8996-X. 
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Why  ODM?  A  Documentable  Survey  &  Synthesis  Method 

lEnforcM 
tfie  “what  It  to” 

from  the  “what  you  went  It  to  be' 


•  Domain  Lexicon 

•  Domain  Intenaional  Definition 

Domain  Extensionai  Definition 

-  exemplar  aet 

-  representative  set 


Domain  Stakeholder  Model 
Domain  Genealogy  Model 
Domain  Interconnection  Model 


Supports  bnpsrttalty 

hosed  on  observation 

focuses  modeling  on  what  you  can  see 


Alow*  CARDS  to  adopt  a  “Don't  Invent  Her*' 


i  —a  Session  /Kr> 

y  Archhactura-Basod 
{  Reuse  Tools 


Why  ODM?  A  Documentable  Survey  &  Synthesis  Method 


The  descriptive  phase  of  ODM  is  intended  to  focus  lie  analyst  on  describing  what  the  system(s)  is  and  dis¬ 
courages  “creative'  enhancements  and  personal  bias  (Has  is  left  to  the  prescriptive  phase).  Hence,  obser¬ 
vation  of  exemplars  in  the  domain  of  analysis  is  focused  on  what  exists  and  what  can  be  seen.  So  rather 
than  trying  to  observe  and  synthesize  aN  at  once,  impartial  observation  allows  an  objective  view  ol  the  do¬ 
main  exemplars.  For  CARDS,  this  approach  is  attractive  insofar  as  we  can  collect  as  much  information  about 
software  architecture  representations  and  not  have  to  try  to  re-invent,  or  invent  on  our  own  representation. 
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Why  ODM?  A  Documentabte  Survey  &  Synthesis  Method 


OigMladM  Domain  Madilng  (QOM),  a  STARS  Domain  Engnaaring  matioddogy,  wm  aalactad  and  todomd  lor  daWirranwg  ih* 
CMOS  aofbmm  aroMaatom  mpmaiidaMen  (BAR)  Tha  Domain  of  Foeua  (DOF)  was  pm  aalactad,  an  annolatad  btdiograptiy  oonv 
pdad 

~-m«fn  Laxioan  Souraaa  Inciuda:  IEEE  Sti  810.12;  Qartan  ft  Shaar;  Pony  &  Wo*  Saixidara,  Horawta,  Maxim;  Walnau,  ale. 
totanaioaal  Do  am  In  DdMtw  •  Rdaa  for  Indudon  and  axcfcjanxi:  A  wpmaamaion  a  mdudad  in  tta  SAR  daman  H  tt  ia  a  daaagn 
mpmaantnien  tor  al  laaat  aoma  aapaola  of  aotoaom  architac&ia.  A  rapmaantaton  it  not  Indudad  In  tha  8AR  domain  If  I  tocuaaa  pri- 
marly  on  mqdmmanta,  dataBad  dadgn,  or  dgoridaaa. 

Baanatond  Pm  aw  In  -  Exampia  8ARS  Including  «w  Emmplar  (Com)  aat  KAPTUR.  UNAS/SALE;  Booch  Object  Onantad  Dadpi; 
Slotomate,  R-Rapido:UtEANNA;  CAD— ;Boidctlna: QailanASlinar  toacnomy  of  arddtocijoaiyiaa;  Counter  aat  mqudamantoapoo- 
Doadonlanguagea;POl;progwinmlngtonguagaa.A«opweantolMeaatleae>toaatotlweaimp>araattdttchleanalyiedlndomi.ltio 
twbaala  ler  dwdaaadpdm  modal  d  SAR  taaaaaa.Dwwamnliapiaaaniattim  aat  Ik  KAPTUR;  UNASlSALE;Qailand  A  StwwWxon- 
omy  of  aiddfaduml  atyfaa;  ROSE-2;  p-  Rapkfa;  ULEANNA;  DCOS/RDO. 

Doomlw  Smlmhotdcr  Modal  provtoaa  oenfart  of  hear  an  8AR  la  mlalad  to  idea  of  poopla  In  a  aoftamm  ergandaion.  Tha  nauee  tech- 
/wfagyproddardamlepaAnalnfalna  dm  8AR.  domfapa  faofa  and  proddaa  fadwotegy  tranadon.  Tha  domain  ORptnaariapmaanfa  dm 
domain  apodloaoltwamarchttoatumff)6SA)nt>o  SAR  and  qudWaafaiSdaoomponanfaboaod  on  fwDSSA.  Tha  tppteaUenmtglnmr 
uaoo  dw  088A  and  faofa  to  buddAnaMain  aytfama 

Damaln  Qanaalogy  Modd  proddaa  hiafatfaal  Infamwicn  on  tha  domlopmant  d  dm  domain  (uaofd  In  daoerfadva  modeling). 

Dawalii  imaroonoaoMan  Modal  ahewa  tha  mlallona  bataaan  domain  dfacua  and  ralatad  domalna. 

OeoorlpttooModaHatoalumodtoamembem  of  the  repmaeniatm  aat  modeled  IndMdualy  In  RLF-Thaaetoafame  am  toaneyrtho- 
afaad  Into  a  pmoodptim  modal  fa  tdacaaa.  too  pmacdpdm  modal  ■  the  eoffam  archlfactum  mpmaentaton  (SAR). 

Ilaqulmmanm  fortho  Piaoortpttva  Modal  (SAR):  muai  tocHtate  arcHfaoaaxanWc  muaa;  muat  mpmaant  moat  BoD  aoftwara  arehi- 
tacturaK  muat  aupport  intacmctva  oompoarton  of  tyatama,  muat  aaaiat  oomponant  qualification;  muat  ba  onoodabia  in  STARS  Rauaa 
Library  Framework  (RLF). 
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ATF  Summary  and  Status 


•  Domain  Definition  and  Scope: 

•  first  step  in  formalizing  the  CARDS  modeling  approach 

-  provides  technical  input  to: 

-  Architecture  and  Reuse  Seminar 

-  Reuse  Adoption  Handbooks 

-  Evaluation  of  UNAS  and  other  similar  technologies 

•  Descriptive  modeling  in  progress 

•  Plans 

•  Complete  ODM  process  on  SAR  domain 

-  Develop  explanatory  examples 

-  Use  SAR  on  to  describe  real  systems 
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ATF  Summary  and  Status 


To  dale,  the  CARDS  Architecture  Task  Force  has  completed  the  Domain  Definition  and  Scope  lor  the  soft¬ 
ware  architecture  representation  domain.  Early  results  of  this  work  are  being  presented  at  this  seminar  and 
workshop  and  is  also  input  to  the  CARDS  Reuse  Adoption  Handbooks,  to  our  tools  evaluation,  and  to  our 
domain  engineering  activities  in  the  Command  Center  domain. 

Descriptive  modeling  of  the  domain  of  software  architecture  is  in  progress.  In  addition  to  the  coordination 
during  this  seminar,  CARDS  is  in  contact  with  numerous  reuse  organizations.  The  CARDS  program  wel¬ 
comes  the  opportunity  to  collaborate  with  interested  DoD,  academic  and  industry  partners. 

The  ATF  plans  to  complete  the  ODM  process  on  SAR  domain,  develop  explanatory  examples  and  make 
the  results  part  of  the  CARDS  operational  library. 
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Roadmap  for  this  Session 


CARDS  Scientific 


CARDS  Engineering 


•  AichlMekm  Task  Foret 

•  Organizational  Domain  Modatlng: 
Domain  of  Software  Archltactura 
napreaamatton 

•  Component  QuaMcatlon 

•  System  Composition 


CARDS  Transition- to- Practice  »  InSSSStna 


This  page  intentionally  left  Wank. 
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A  Context  for  a  Model-Based  Approach  to  Reuse 

•  Concept  of  “Ibmy  assistance”  varies  by 


•  Component-based  abrades 

•  organised  lor  Match  and  retrieval  of 
Individual  reusable  components 

>  highly-developed,  effective  search 
mechanisms  (rotational) 

-  weakness:  perts-orlentatlon  loses 
context  Information 

•  Model  based  Hbrariee 

•  myarazeo  re*  sauonsifl  sssa  asapwion  or 
domain  models 

•  knowledge  representation  and 
conventional  engineering  notations 

-  weakness:  hard  lo  build  and  get  buy-ln 

•  These  approaches  are  complementary 

•  need  models  and  components 

•  “  certification'  vs.  'quaMcation' 


A  Context  for  a  Model-Based  Approach  to  Reuse 


CAROS  represents  an  alternative  technology  approach  to  reuse  libraries,  one  which  is  more  focused  on 
describing  the  context  ol  components  (their  interrelationships  and  their  relationships  to  design,  require¬ 
ments— i.e..  a  domain  model  and  an  architecture).  We  have  found  it  useful  to  distinguish  two  classes  of 
reuse:  a  model-based  approach,  end  a  component-based  approach.  The  model-based  approach 
(CARDS)  pursued  by  CARDS  attempts  to  capture  domain  knowledge  as  formal  models,  and  attempts  to 
use  this  encoded  knowledge  to  automate  reuse  through  the  use  of  knowledge-based  assistants.  It  is  also 
possible  to  consider  model-based  approaches  based  on  formal  methods. 

Note  that  component-based  libraries  can  be  domain-specific  or  domain-independent,  while  model-based 
libraries  tend  to  be  domain-specific. 

Also  note  that  these  approaches  are  complementary.  Model-based  libraries  need  components  to  work, 
while  component-based  libraries  could  develop  large  component  populations  in  anticipation  of  encoding 
knowledge  about  their  use  in  various  contexts. 

Examples  of  component-based  Kbraries:  STARS/ASSET,  DISA/DSRS 
Examples  of  model-based  libraries:  AT&T  LaSSIE,  CARDS,  NASA/KAPTUR. 
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Model-Based  Reuse: 


Certification  and  Qualification 


Component-Based  Perspective 


component 

TTT 


Object  Focus; 

•  whet  hind  it  It? 

•  what  does  It  do? 

•  how  good  it  It? 


•  powerful  naming  achomo 

•  equate  “whet  It  la"  with 
“when  to  And  IT 


FORM 


CfirtiflcationtL 

-  the  process  tor  deternil plug  whether 
a  eyetem  or  component  te  suitable 
for  operational  use. 


Model-Based  Perspective 


Context  Focus 
•  what  uses  It? 


•  what  dose  It  use? 

•  when,  why  Is  It  used? 


I—  CONTEXT 


•  equate  “how  It  le  used* 
with  “where  to  find  If* 


Qualification**; 

-  the  proceaa  for  determining  the  degree  of 

UOiO  ftuSuAAji  a  Mtaiasitsal  #4aasM\  aikd  ia 

fn  MiwMn  i  component  iionnj  mo  i 
particular  design  (context). 
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Model-Based  Reuse:  Certification  and  Qualification 


While  Certification  measures  the  goodness  of  a  component  in  a  rather  generic  fashion,  Qualification  of  a 
component  in  a  fibrary  provides  assurance  that  this  component  is  suitable  for  the  domain. 

The  focus  that  component-based  and  model-based  reuse  libraries  place  on  objects  is  fundamentally  efif- 
terent.  in  a  component-based  approach,  he  emphasis  on  components  in  the  library  focus  on  “whar  the 
component  is  and  how  “good-  is  it  This  approach  serves  as  a  sofid  foundation  in  developing  a  rich  and 
powerful  classification  scheme  for  equating  “what  the  component  is"  to  “where  to  find  ir  allowing  the  de¬ 
velopment  of  sophisticated  mechanisms  to  search  and  retrieve  components  matching  the  search  criteria. 

In  a  model-based  approach  the  focus  is  more  on  how  the  component  fits  in  the  application  domain  for 
which  it  is  intended  to  be  reused.  In  this  approach  he  emphasis  is  on  “what  uses  ir  and  “what  does  it  uro’ 
which  is  an  intent  to  preserve  some  or  most  of  the  context  information  lost  in  component-based  approach- 
es.  Adtflionaly,  ttie  model-based  approach  emphasizes  on  the  “whenr  and  “why*  a  component  is  used  in 
the  application  domain  where  the  intent  is  to  tie  the  operational  context  or  requirements  for  a  components 
use.  This  approach  serves  as  a  foundation  fa  semantic  search  classification  schemes  which  relate  how  a 
component  is  used  to  “where  to  find  if. 

While  CARDS  Libraries  adhere  to  a  model-based  paradigm  in  support  of  domain-specific  reuse,  CARDS 
beieves  that  component-  and  model-based  approaches  are  complementary,  not  diametrical. 
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Genealogy  of  CARDS  Qualification  Process 


Software  Reuse 
Initiative  Libraries 


Genealogy  of  CARDS  Qualification  Process 


The  CAROS  qualification  process  was  synthesized  tram  PRISM,  ASSET  and  DSRS  (RAPID)  certification 
processes  and  refined  to  suit  CARDS'  domain  specific  fibrary  approach  to  reuse. 

Reuse  fibraries.  Hke  DSRS  and  ASSET  (which  tend  to  focus  more  on  components),  are  geared  more  to¬ 
wards  a  certification  view  of  reusable  assets.  The  CARDS  fibrary  (which  tend  to  focus  more  on  the  form 
and  context  of  components)  is  geared  more  towards  a  quafification  view  of  components.  This  does  not  im¬ 
ply  that  component-based  libraries  are  purely  certification  oriented  and  conversely  that  model-based  librar¬ 
ies  are  purely  qualif  ication  oriented.  The  CARDS  Qualification  Process  recognizes  the  complementary  role 
that  certification  and  qualification  should  play  in  the  assessment  o(  components  for  reuse  fibraries. 

Clearly,  a  component-based  library  may  not  be  so  interested  in  the  'domain',  or  context,  that  a  component 
is  intended  to  operate  —  for  t1x*e  quafification  does  not  have  a  rote.  However,  it  would  be  ifi  conceived  for 
a  model-based  library  to  totally  ignore  certification  issues  when  qualifying  a  component  for  a  domain. 
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Qualification  Process 


Qualification  Process 


For  Qualification  the  emphasis  is  on  domain  criteria  and  generic  architecture.  For  Certification,  the  em¬ 
phasis  is  on  general  characteristics  such  as  reliablity,  maintainability,  and  portability. 

The  Qualification  process  was  developed  for  the  Command  Center  domain,  but  is  applicable  to  other  ver¬ 
tical  domains  with  large  grained  COTS/GOTS/pubiic  domain  components.  The  component  classes  repre¬ 
sent  horizontal  domains.  The  qualification  results  are  modeled  in  RLF  and  used  in  the  qualification  loot, 
system  composition  tool.  Evaluation  reports  are  also  available  in  the  CARDS  library. 

During  Vie  Mentffl&atlon  phase  a  list  of  potential  products  suitable  tor  the  domain  is  compied  and  infor¬ 
mation  required  tor  product  screening  is  obtained.  During  Screening  the  fist  of  potential  products  is  prior¬ 
itized  so  that  more  detailed  evaluations  can  be  performed  with  a  high  acceptance  rate.  Software 
Development  Folders  (SDF)  are  produced  tor  products  which  pass  screening.  Products  which  do  not  pass 
screening  are  archived.  The  purpose  of  the  Evaluation  phase  is  to  measure  the  selected  Configuration 
Item  against  domain  and  common  criteria  and  to  produce  the  evaluation  report 

Domain  Criteria  measure  components  against  the  domain  and  generic  architecture  (i.e.  toe  form,  fit  and 
function")  and  are  divided  into  component  constraints,  architectural  constraints,  and  implementation  con  ¬ 
straints.  Domain  criteria  are  determined  for  each  component  class  (horizontal  domain),  and  selected  do¬ 
main  criteria  marked  critical  for  vertical  domain  (command  center).  Criterion  sources  include:  DISA 
Command  Center  Design  Handbook,  PRISM  reports.  Common  Criteria  measure  domain  independent 
evaluation  of:  reliability,  maintainability,  us;  maturity,  portability,  and  cost. 
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Qualification  and  Architecture 


Improvements 
(e.a.  better  constraints ) 


Architecture 

Refinement 


Qualification 

Process 


feedback 

(e.g.  better  designs) 
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Qualification  and  Architecture 


There  to  on  interesting  interdependency  between  architecture  and  qualification,  which  can  be  expressed 
as  a  positive  feedback  loop. 

Architecture  Refinement  can  be  thought  of  as  addressing  three  aspects  of  architecture:  1)  the  theory  of 
software  architecture  (representation,  evaluation,  processes,  eta);  2)  a  specific  application  architect  ure/- 
design;  and  3)  the  manner  in  which  CARDS  represents  the  appScation  architecture  in  the  CARDS  library. 
As  a  result  of  undergoing  qualification  efforts,  feedback  can  occur 

Architecture  Theory:  better  understanding  of  the  evaluation  of  non-functional  characteristics  of  software 
architectures. 

AppficaUon  Design:  a  tuned  design  which  expresses  more  trade-off  information  regarding  the  selecfion  of 
components 

SAR:  a  tuned  representation  which  reflects  advances  in  theory  and  capture  of  new  and  cfifferent  kinds  of 
trade-off  information. 
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Model-Based  Approach  to  Reuse 


liodel  contains  information 
-  about  ths  domain 

•  about  tha  components 

roimal  modal  of  domain  products 
supports 

*  lonp-llvad  domains 


dsvoiopmsnt  of  multlpls  rsuas 
oomponwin  n,  tyufini  our 


DMarant  appraaebaa  to  formal 
modsilng 

-  domain  languages 

*  module  Interconnection 
languages 

•  expert  systsm  shells 
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Model-Based  Approach  to  Reuse 


The  CAROS  program  has  adopted  a  model-based  approach  to  developing  reuse  technologies.  More  spe¬ 
cifically,  to  be  effective,  our  approach  b  to  define  owBxary  model  in  tto  context  ol  a  domain,  HtiaMy  Com- 
mend  Centers.  This  sfide  depicts  die  architecture  lor  a  domain  specific,  model-based,  reuse  library. 

The  fibrary  store  %varehouses*  the  components  stored  in  the  fibrary.  The  library  model,  or  domain  model, 
captures  the  products  o<  domain  analysis  and  defines  the  relationships  between  the  components  specific 
to  a  particular  domain.  Reuse  tools,  which  leverage  the  information  and  relationehipe  encoded  in  the  fibrary 
model  to  support  a  number  ol  services  avaiabie  to  CARDS  library  users. 

The  domain  model  gives  ub  a  formal  encoding  of  the  relationships  between  the  requirements,  architecture 

and  impiemertatioa  The  encodmg  can  become  the  basis  for  a  library  Irameworferi  which  to  build  applica¬ 
tions  to  leverage  those  relationships  and  perform  a  variety  of  services.  This  is  vitaly  important  in  post-de¬ 
ployment  maintenance  as  those  initially  involved  in  building  the  domain  model,  defining  die  system 
architecture,  and  building  the  implementation  are  most  fikely  not  the  individuals  that  will  be  making  modi¬ 
fications  to  dial  system  throughout  its  file  cycle. 

The  focus  of  die  domain  model  in  a  domain-specific  reuse  fibrary  is  to  bring  together  an  the  information 
drat  went  into  the  architecture  and  implementation  of  the  system.  The  fibrary  then  becomes  a  vital  tool  in 
understanding  the  appfication  domain  being  maintained. 

Additionally.  CARDS  has  employed  die  STARS  product,  Reusabilty  Library  Framework,  (RLF),  as  the 
modeling  paradigm  to  support  the  encoding  of  the  domain  model  and  the  applications  which  access  that 
model. 


Model-Based  Approach  to  Reuse 
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Model-Based  Approach  to  Reuse 

The  CARDS  approach  to  Sbrary  modeling  is  to  characterize  the  domain  model  in  terms  oi  three  sub-mod¬ 
els,  each  describing  different  kinds  of  constraints: 

•  requirement  constraints  -  for  instance,  those  imposed  by  the  D1SA1  Command  Center  Design 
Handbook  (CCDH), 

•  domain  architecture  constrains  -  those  constraints  imposed  by  a  specific  architecture 
implementation  such  as  the  PRISM2  Generic  Command  Center  Architecture  (GCCA);  and 

•  implementation  constraints  -  those  constraints  imposed  by  a  specific  COTS3  tool  or  software 
wrappers  needed  to  integrate  reuse  components. 

Also  expressed  are  constraints  which  map  between  those  sub-models: 

•  allocation  constraints  map  between  requirements  and  architecture -thus  showing  traceability 
how  a  specific  part  of  the  architecture  satisfies  portions  of  the  requirements; 

•  composition  constraints  map  between  architecture  and  implementation  •  detailing  how  the 
architecture  is  satisfied  by  a  particular  implementation  brought  together  from  the  library  store. 

The  goal  of  domain-specific  reuse  library  is  to  elicit  reuse  at  higher  levels  of  abstraction:  requirements,  ar¬ 
chitectures,  systems  and  subsystems  as  well  as  components.  This  increases  our  ability  to  readily  adopt 
reuse  for  a  specific  domain. 

Significant  benefits  are  achieved  by  focusing  on  model-based  approach  to  capture  the  architecture  and 
constraints  to  move  the  architecture  along,  avoiding  the  tendency  of  erosion  and  drift. 


''Defoe  hformatioo  Syvara  Agency  (DtSAJ 
1  Portable.  Rcuabie.  biepaled  Soft wue  Module,  (PRISM) 
Commercial  off-tfae-obdf  (COTS) 
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Model-Based  Approach  to  Reuse 


This  slide  provides  a  more  reafistic  view  of  where  CAROS  technology  is  moving  with  respect  to  domain- 
specific  reuse  libraries.  The  Command  Center  domain  is  our  initial  domain,  but  other  domains  are  planned. 
Therefore  our  reuse  tools  are  designed  to  operate  on  any  domain  model. 

The  first  prototype  tor  the  CARDS  CCL&rary  reuse  tod.  the  system  composition  application,  supports  rap- 
id  integration.  The  system  composition  application  wort®  by  eidteig  input  Irom  the  ibrary  user  in  order  to 
identity  the  constraints  that  an  operations)  command  oenier  must  satisfy.  The  use  ot  deductive  interenong 
in  conjunction  with  the  constraint  network  allows  the  system  composition  application  to  query  the  user  for 
the  minimal  amount  of  information  necessary  to  support  automatic  compositior  of  a  prototype  system.  Al¬ 
though  the  system  composition  application  is  targeted  to  the  development  phase,  its  computational  model 
wil  apply  to  post-deployment  support 

Other  reuse  tools  envisioned,  that  to  apply  themselves  to  poet-deployment  maintenance,  are  a  change  im- 
pact  analysis  and  component  qualification  application.  The  change  impact  analysis  application  built  on  the 
allocation  constraint  network  would  assess  changes  in  requirements  on  the  architecture.  Further,  on  the 
composition  constraint  network,  it  would  assess  the  impact  of  changes  in  the  architecture  on  the  imple¬ 
mentation.  The  component  qualification  tool  would  also  leverage  the  composition  constraint  network  to 
suggest  alternate  components  in  an  implementation  during  adaptive  maintenance. 

Also  important  to  note  about  this  slide  is  that  there  is  not  one  library  store  fa  Command  Centers  and  an¬ 
other  ibrary  store  tor  toe  next  domain.  Rather,  each  library  model  references  those  components  in  the 
store  which  are  qualified  and  applicable  tor  its'  domain.  It  would  be  very  Ikely  that  domains  which  both 
share  the  concept  of  a  database  management  system  would  both  “point"  to  the  same  component  in  the 
Nbrary  store  which  satisfy  toe  constraints  placed  on  DBMSs. 


306 


System  Composition 


System  Composition 


The  objective  of  system  composition  is  to  provide  commend  carter  library  users  with  tools  to  automate  the 
composition  of  new  command  centers,  or  portions  thereof,  based  on  user  requirements  from  components 
in  the  library  model.  The  approach  is  to  apply  user  input  to  the  library  model  to  produce  prototype  demon¬ 
strations  of  systems,  assist  users  in  the  decision  making  process  of  tanking  new  systems,  and  when  pos¬ 
sible,  provide  users  with  the  actual  software  to  build  them. 

This  slide  provides  a  top  level  view  of  the  system  composition  appfication.  There  are  three  inputs  to 
“System  Composer:  a  model  of  the  Command  Center  library,  target  system  constraints  elicited  from 
user,  and  a  rule-base  tor  system  composition  and  heuristics  tor  building  the  system.  The  outputs  of 
system  composition  tool  are  system  demonstrations  and  composed  systems  (or  portions  of  a  system) 

The  System  Composition  Tool  prototype  has  provided  a  reference  tor  what  we  expect  out  of  a  software 
architecture  representation,  that  is  what  are  the  products  a  software  architecture  should  be  helping  to  pro¬ 
duce. 
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Roadmap  for  this  Session 
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CARDS  Tech  Transfer  in  Practice 


CARDS  Tech  Transfer  in  Practice 


The  rectangles  in  this  slide  represent  the  CARDS  Phase  3  project  areas  and  how  they  interact.  Notice  that 
Training  and  Education  span  our  entire  project.  CARDS  contact  with  the  Reuse  Community  affects  the  oth¬ 
er  technical  projects:  Domain  Engineering.  Library  Development  and  Franchise  Concepts.  The  processes 
and  products  produced  by  these  groups  is  then  transferred  to  franchise  organizations  wishing  to  establish 


CARDS  Tech  Transfer  Approach 


KAPTUR,  ROSE-2,  UMAS; 
others  targeted 

•  Architecture  seminar 

•  “ Alternative  views” 


jp~  . . j 

Organizational  Analysts 
Concepts  o<  Operation 

Synthealsftpptoallon  ot 
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\  Component/Tool  Developer's  Handbook  } 
f  Acquisition  nsnaoooic 
\  Direction-Level  Handbook 
L  Technical  Concepts  Document 
i-  Legal  and  Acquisition  Issues  Document  ) 
\  and  many  mors.. 
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CARDS  Tech  Transfer  Approach 


CARDS  has  two  main  avenues  for  transfer  of  technical  information,  the  Handbooks  and  Franchising  activ¬ 
ities. 

The  handbooks  include:  Engineering  Handbook,  Library  Operations  Policies  and  Procedures.  Technical 
Concepts  Document,  Acquisition  Handbook,  Direction  Level  Handbook,  Component  and  Tool  Developer's 
Handbook.  CARDS  is  also  developing  Model  Contracts/Agreements  and  is  conducting  Market  Studies 

CARDS  reuse  support  services  are  available  to  Government  organizations.  Those  services  include  imple¬ 
mentation  of  me  CARDS  blueprint  according  to  the  Handbooks  and  CARDS  Franchise  Plan. 
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The  Franchise  Approach  to  DoD-wide  Reuse 


CAROS  seeks  to  create  permanently 
established  hum  capabilities  within  DoD 
organizations  (Le.,  ’franchises’) 


Franchise  Plan  la  CARDS  tool  to  apply  the 
reuse  blueprint  to  DoD  organisations 


Ones  established,  franchises  may  create, 
manage  and  support  use  of  domain-specific 
assets 


Franchise-developed  rouse  capebWtles 
become  part  of  a  larger  DoD  reuse 
Infrastructure 


Goal  Is  to  support,  and  Integrate,  reuse 
capabiOtles  across  multiple  organizational 
levels,  and  across  government  and 
contractor  boundaries 
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The  Franchise  Approach  to  DoD-wide  Reuse 


The  CARDS  approach  to  technology  transfer  includes  a  heavy  emphasis  on  direct  involvement  between 
CARDS  and  technology  adopting  organizations.  We  refer  to  such  organizations  as  "franchisee  " 

We  view  Franchising  as  a  process-feedback  approach  to  incremental  adoption  of  reuse  in  the  DoD.  The 
approach  recognizes  that  reuse  capabifities  (domain  expertise,  product  ines,  etc)  exist  within  DoD  prod¬ 
uct  and  logistics  centers,  and  therefore  reuse  adoption  must  take  place  within  these  organizations.  Thus. 
CARDS  provides  services  to  support  an  organization  to  adopting  reuse,  but.  ultimately,  the  reuse  products 
and  experience  generated  from  the  use  of  reuse  technology  and  methods  must  be  generated  by  DoD  or¬ 
ganizations.  CARDS  views  Franchising  as  a  means  to  initiate  the  transition  activity,  and  the  channel  the 
resulting  products  and  lessons- teamed  into  future  franchising  activities. 

Note  that  CARDS  joint-development  activities  are  not  restricted  to  only  one  kind  of  organization  We  cur¬ 
rently  have  development  activities  underway  at  the  National  Security  Agency  and  Air  -ores  Sacramento 
Air  Logistics  Center,  as  well  as  with  the  Air  Force  PRISM  program  (who  serve  as  the  domain  experts  and 
prototype  developers  for  the  major  elements  of  the  CARDS  library). 


316 


Recognizing  Franchise-Unique  Context 


i  li  V  I'l-'il  ' 


organizations 

*  CPfswwsa  WSwS®  we  milK  ml,  Ing 

commitment  to,  nun 

-  alt  of  the  usual  aocfcVpoHtlcal  variations 

Technology  transition  muat  recognize 
organizational  rtverstty 

-  afferent  business  objectives 

•  afferent  starting  points  (capaMltlaa) 


Technology  transition  must  also  recognize 
tadmotogy  dhrerslty 

-  domain-induced  tadmotogy 
raqulramanta 

-  tadmotogy  dvaialty  among  DoD 


conUnuousadvanoaaandavoiutlonln 
software  daalgn  and  davotopmant 
tadmotogy 


To  be  suooassM  at  technology  transition,  CARDS  believes  It  is  inevitable  that  organizafion-specific  needs 
be  addressed.  Specifically,  no  two  organizations  are  in  a  current  stale  of  "reuse  maturity"  (however  one 
wishes  to  define  his  concept),  nor  do  any  two  organizations  share  the  same  culture,  business  climate  or 
strategy  objectives.  In  short,  the  context  Wo  which  a  technology  is  being  transferred  shapes  toe  approach 
taken  to  undertake  the  transfer. 

Our  approach  to  franchising  is  based  upon  a  flexible,  3-tiered  analysis,  consulting  and  joint-development 
protect  model.  CAROS  has  developed  materials  to  conduct  organizational  analysis  based  upon  organiza¬ 
tional  development  prindptes,  software  process  maturity  prindptes,  reuse  principles  end  technology  trans¬ 
fer  principles.  These  materials  are  intended  to  be  used  to  aid  in  identifying  organization-specific 
requirements  for  the  development  of  a  reuse  implements  toon  plan.  (Note,  these  materials  have  only  recent¬ 
ly  been  developed,  and  have  not  yet  been  applied). 

It  is  possible,  of  course,  to  assist  an  organization  in  developing  a  reuse  implementation  plan— and  we  have 
provided  sendees  to  the  Air  Foroe  to  do  so  in  one  instance-- without  having  created  an  orgarezational  pro¬ 
file.  While  CARDS  befieves  that  this  may  make  the  reuse  implementation  plan  less  effective  (or  at  least 
increase  the  Ikefihood  that  the  plan  win  be  less  than  optimal),  it  is  sometimes  necessary  to  aooepf  such 
planning  Imitations  in  the  name  d  making  even  smaN  progress  in  initiating  organization  and  business  prac¬ 
tice  changes  to  support  reuse. 

Finaly,  there  is  also  scope  tor  inserting  reuse  techniques  into  an  organization  at  the  "grass  roots’  level 
through  direct  prototype  development  efforts  with  organizations. 


I 

CARDS  Team  Members 

•  CAROS  is  managed  by  ESC/AVS 

Mr.  Robert  Lencewicz,  Program  Manager  (617)  377-9369 

•  Unisys  Corporation  is  the  prime  contractor 

•  Subcontractors  represent  a  highly  diverse  and  skilled  team 

DSD  Laboratories 

Electronic  Warfare  Associates 

Azimuth 

DN  American 

Galaxy  Global  Corporation 

Strictly  Business  Computer  Systems,  Inc. 

HGO  Technology,  Inc. 

AETech  Inc. 
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Category  Building  Context  Setting 


Central  Archive  for  Reusable 
Defense  Software 
(CARDS) 

Software  Architecture  Seminar 

16  November  1993 

Panel  Discussion 


/Lies _ 

Panel  Discussion 
Architectures  in  Practice 

Mr.  T.  F.  “Skip”  Saunders,  Mitre  Corporation 

Mr.  Hans  Polzer,  Unisys  Corporation 

Mr.  Stan  Levine,  US  Army  Communications 
Electronics  Command  (CECOM) 


Capt  Frederick  Swartz,  Training  System  Program  Office,  ASC/YTE 


Views  on  Architecture  and 
Reuse 


T.  F.  Saunders 

16-27  Nov  93 


MURE 


Outline 


a  Goals: 

Interoperability,  Changeability,  Cost  Effectiveness 
a  Views  on  Architecture 
e  Program  Management  Perspectives  for  Reuse 
a  Acquisition  management  of  Architectures  - 

-  A  strategy  to  promote  Reuse 

-  A  strategy  dependent  on  “Popular”  Standards 
a  Interoperability 
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Emerging  interest  in  “Architecture” 

•  Driven  by  desire  for. 

-  more  changeability  -  “varUcal"  flexibility 

-  more  interoperability  -  "horizontal"  flexibility 

-  cheaper  development  -  commercial  product  exptoltetion 

•  Technical  solution  Is  (and  has  been  for  a  long  time)  envisioned 
(but  not  proven)  to  be  essociated  with  technology  that  is  well 
ordered  (Le.  well  structured,  modular,ete.) 

-  Vertical  flexlbittty  comes  from  framework  baaed  system  structure 

•  “open”  etandarde  for  components  within  the  system 

•  mix  of  proprietary  and  non-proprietary  products 

-  Horizontal  flexibility  comes  from  standard  protocols 

•  "open*  protocols  for  exchanging  bits 

•  data  element  standardization  for  Interpreting  the  bits  exchanged 
or  translators 

-  Commercial  trends  are  providing  technology  to  support  both  vertical 
and  horizontal  flextelllty 

MITRE 
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“Open”  Concepts  - 

An  important  distinction  in  definitions 
e  Open  Systems: 

-  A  system  is  "open"  if  It  has  publicly  known  interfaces  such 
that  its  components  may  be  treated  as  “black  boxes” 

-  A  system  Is  a  “desirable  open”  system  H  the  interfaces  are 
supported  and  used  by  a  wide  variety  of  vendors 

Note:  Publicly  known  &  publicly  owned, 

Le.  an  open  system  may  heve  proprietary  component* 

e  “ Proprietary ”  allows  financial  reward  for 

-  achieving  large  market 

-  improving  products 

-  maintaining  backward  (or  forward)  compatibil'fy 


MITRE 
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Three  Objectives  for  “Information 
Architecture” 


Changeability 
(Vertical  flexibility) 


Interoperability 

(Horizontal  flexibility) 


and  Schedule 

(Commercial  product 
exploitation  -  “beet  value”) 


Saak:  High  Changeability 
High  Interoperability 
Low  Coat  A  Short  Delivery 
Times 
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Outline 


e  Goals: 

Interoperability,  Changeability,  Cost  Effectiveness 
e  Views  on  Architecture 
e  Program  Management  Perspectives  for  Reuse 
e  Acquisition  management  of  Architectures  - 

-  A  strategy  to  promote  Reuse 

-  A  strategy  dependent  on  "Popular”  Standards 
e  interoperability 
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Popular  definitions  for  “Architecture*’ 

(partial  list) 


•  Organizational 

-  Functional  •  Mission  tasks  (subtasks)  to  be  dona 

-  Logics!-  Communications  links  batsman  functional  areas 

-  Physical  -  Resources  used  to  execute  functions 

•  System 

-  Components  -  Major  elements  of  system 

-  Connections  •  Links  between  components 

-  Constraints  •  Environment  A  behavior  bounds 

e  Software 

-  Components  -  Major  sw  design  relevant  structures 

-  Connections  •  Data  &  control  flow  mechanisms 

-  Constraints  •  Performance,  construction  rales  A  resources 


MITRE 
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Different  Views  of  Architecture 

Academic  View 

Academic  View 

Components 

Connections 

Constraints 
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Different  Views  of  Architecture 

Software  Developer1!  View 


Different  Views  of  Architecture 

Software  Developer’s  View  (Notes  continued) 


Different  Views  of  Architecture 

Standard  Protocol  Community  View 


Different  Views  of  Architecture 

Government  Standards  Community  View 


Different  Views  of  Architecture 

Mission  Organization's  View 


Different  Views  of  Architecture  - 

Summary 


•  Observations 

-  There  may  be  other  views  of  architecture 

-  Thera  Is  no  common  nomenclature  for  describing 
different  aspects  of  architecture 

e  Recommendation 

-  Widely  recognized  and  accepted  technique  for 
describing  architectures  is  needed  to  allow 
architectures  to  be: 

•  Requested 

•  Evaluated 

•  Preserved 


Mills 
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Outline 


e  Goals: 

Interoperability,  Changeability,  Cost  Effectiveness 
e  Views  on  Architecture 
e  Program  Management  Perspectives  for  Reuse 
e  Acquisition  management  of  Architectures  - 
-•  A  strategy  to  promote  Reuse 
-  A  strategy  dependent  on  “Popular”  Standards 
•  Interoperability 


MURE 
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A  Domain  Managers  Motivations  - 

Reusable  products  to  fulfill  “corporate"  perspective 


Number  of  Different  Syeteme 
that  can  use  common  components 


MITRE 
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A  Program  Managers  Motivations  - 

The  missing  “corporate”  perspective 


MITRE 


343 


Future  Acquisition  Approach 


Outline 

•  Goals: 

Interoperability,  Changeability,  Cost  Effectiveness 
e  Views  on  Architecture 
e  Program  Management  Perspectives  for  Reuse 

•  Acquisition  management  of  Architectures  - 

-  A  strategy  to  promote  Reuse 

-  A  strategy  dependent  on  “Popular”  Standards 

•  Interoperability 


Interoperability  = 

Interconnect!  vity  +  Data  Compatibility 


•  C4I  systems  must  exchange  Information  for  system 
interoperability 

•  interopersbllity  implies 

-  Interconnection  protocols  allow  systems  to  exchange  bits 

-  Systems  within  a  user  community  have  same  representations 
for  the  same  Information,  or  else  a  means  for  translating 
between  systems 

•  Existing  C4I  systems  send  and  receive  messages 

-  directly  when  they  have  the  same  data  standards  and  same 
internal  definitions  for  data 

-  by  using  translators,  external  or  Internal,  when  they  do  not 
have  the  same  Internal  data  representations 


MITRE 
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Data  Element  Format  Mismatch 

Example 
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Data  Element  Format  Mismatch 

Examples 


MITRE 


Data  Element  Standardization 

Connection  complexity  without  standards  -  Universal  Interoperability 


MITRE 
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BACKUP 


Program  D  Architecture 

Reusable  components 


Mission  Applications 


Technical  Reference  Model 

DODI1S 


Technical  Reference  Model  - 

DISA  Technical  Reference  Model  for  Information  Management  (t  1.3) 


How  to  Derive  the  ‘‘Building  Codes” 


Commercial 
Market  State 
of  Practice 

Provides  products 
Os  term  loss  ad  hoc 
standards 
Provides  migration 
pathways  amongj 
standards 


Air  Force  Standards  &  COTS  Product 
Review 

tabs  assess  compatible  products  a  stda 
Assess  'popularity*  o»  standards 
Test  bed  explores  IntaroperabUty  needs 
and  "tntarpriaa  wide"  prforfnanct 
Dcvaiop  ioo<f  lor  tfcMMdun  pniaviiion 
PflerMxs  legacy  migration  Initiatives 
Partielpate  on  Standards  Advisory  Boards 
Pubash  “Building  Codas*  and  advlsorlaa 


Product  Domain 
Manager 

Select  Building  Codas 
Provide  Funding 


Defense  Information  Systems  Agency 

Determine  consistent  date  definitions 
Recommend  standards  lor  CM  tetaroparabtety 


PMD  Advice  & 
Instructions 

Determines  criteria 
for  building  parmHaj 


MITRE 
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CAPOS  Architecture  Workshop 


Money:  the  Architecture  Engine 


_  CAROS  Architecture  Workshop _ 

Money:  the  Differentiator 

O  Science  vartu*  Engineering 
O  Wee*  venue  Product* 
e  Speculation  vereu *  kneetmont 
9  Point  SokiOone  venue  Perveetveneea 
9  Utile  Honey  versus  Big  Honey 
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UNISYS 


CARDS  AroMsoMS  Workshop 


Architectures:  Saving  Monty 


•  IfaOAtiUW  DOittt  MOk/tiOftM  HiOOif  alUMWfti 

•  Common  alwimm  ndrr<  dW^n  uufi  on  nrfiiifti  lyilwni 

#  A/chit9ctui9  sdoptfon  ctwAm  #  con^potiMf  industry 
•  toacom#  command 

•  iwtoNOOffponant  fcanci  *y«am  cart 

•  ooflpai^atolnpaaaatooftpor^ 

t  UtiMy  of  jfchftactum  focimirftycowyoflinf  lndh<afry 

•  app^ionaivburinaMprobfrms 
•  inenttsd  curtwnar  conddsnostoMSunnos 
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.  CARDS  Aithhsehirw  Workshop 


The  Money  Test: 


If  it  doesn't  attract  Investment  beyond  a  single  product 
or  system,  It  Isn't  an  architecture. 
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CAHD8  Waitaiw. i 

Architectural  Chaos 

•  Ww>  Tochnologloo  creole  orchbecOrtl  ctteoe 

m  Pmdous  orchhechres  no  longer  eost-otloctive 

-  No  estobdthed  orchdeckee  ecus  for  tm  new  technology 

-  No  experience  bese  tar  lafortry  on  srrfmaitir* 

-  Oden  euggeet  new  buemest  models 

-  Example:  advent  ot  cheep,  pcmerlul  desktop  computing 

•  Now  BuiinmM  UodtN  emoto  rnrrmoetunU  ehoot 

-  Architectures  embedded  In  business  models 

-  Component  Musty  Impact 

-  Otten  footnoted  Of  changes  In  technology 

-  May  dive  now  technology  development 

-  Eiemple:  desktop  pt&uhng 

•  Candidate  archttactuno  roroty  ho*  overwhelming  buelnees 

advantages 


•  Induetry  dominance  by  any  given  architecture  not  oseurod 
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Architecture  Adoption: 

A  Positive  Feedback  Loop 

•  Smell  perturbations  In  acceptance  of  an  architecture  con  Initiate  a 
positive  feedback  loop. 

-  Perception  of  architecture  acceptance  a  k oy 

-  Merits  of  architecture  not  always  technically  obvious 

-  Marketplace  acceptance  incressss  economic  return  to  adapters 

-  Eoriy  adopters  gain  more  then  htt  eOoptert  (os  o  rule) 

•  Adoption  snowballs  until  economic  tpo ce  to  ooturoted 

•  Architecture  odopUon  rerely  booed  on  teehnleol  excellence  (eg:  MS-DOS) 

•  Architecture  must  however,  be  utehri  (eg:  MS  Wlndowe) 
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Architecture  Adoption: 
Driving  Investment 


•  Architecture  adoption  means  committing  business  assets: 

-  As  a  supplier 

-  developing  components  to  ft  tie  creMtodure 

-  btakfng  systems  that  rely  on  its  architect** 

-  business  models  for  aahng  these  pnoAicts 

-  special  tooting 
•  Asscustomer 

-buying  products  and  services  based  on  twarchdeaue 

-business  models  thet  depend  on  these  products 
-custom  systems  dmt  rely  on  the  snMscSun 

-  tiling  of  stall  lo  use  these  products 

•  kt  vestment  transcends  Individual  promrcta/aya  lama 

•  MM  Investment  encourages  eddMonet  Investment  tn  seme 
arxMtecture 


•  investments  "foreign’ architectures  tmcuit  to luatky 
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Investment  Constraining  Architecture 

•  Changet  In  an  architecture  are  constrained  by  Investment 

-  existing  component  end  system  base 

-  business  models 

-  staff  training 

-  special  tooling 

•  Importance  of  backward  compatibility  ct  new  Infrastructure  components 

•  Investment  blinds  organization  to  need  tor  new  architecture 

•  New  starts  more  likely  to  adopt  new  architectures 

e  New  architecture  not  likely  to  be  adopted  If  It  requires  large  Initial 

Investment 

•  Large  companies  more  likely  sources  of  new,  hlgh-investment  architects 

-  Requires  management  * vlsionfs )' 

-  Large  discretionary  resource  base  (eg,  Uicrosott  NT) 
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Architecture: 

Tha  Road  to  Bankruptcy 

•  Dynamic  technology  and  buainaaa/aodai  conditions  make  any 

arc hltacsura  susceptible  to  oSaotoacano 

feOmrj  VnWOTNrJi  V)  09990  BrC/WfCTUrW 

-  high  Internal  costs 

m  wdttnQ  amtonm  6m  fccui 

-  datvertng  products  net  desired  by  the  general  market 

nmyaHMi  OmmjWQ  mfO  wwfJtmUmi  ■uimn  VtfMCnPO  Oj  909  Of 
tuMalMMM# - •  Mm  - »-■* - «- - ‘  ■t.i,,  ,ii-  ■■  »-  - 

VTivfiniBni  m  inp  ofpnPP  or  JnnMcn/rar  HRiOff)0  fo  corponm 
structure 


•  Sertlch  to  naerer  technology  often  comes  after  others  have  aetabtshed 
market  poatOona 

-  recovery  unUtaiy 

-  button  el  eU  architecture  investment  $81  exists 

- UNiSYS 


CA»ma  Wortaftop 

Managing  Architecture  aa  a  Business  Procsss 

•  Organization*  need  to  manege  architectures  as  an  Integral  part  of  toa 
buaktasa  process 

-  command  sizable  investments 

-  Impact  underlying  business  models 

-  can  achieve  business  success 

-  can  destroy  an  enterprise 

•  Organizations  need  to  deal  with  multiple  architectures  and  their 
Interaction! 

-  identifying  and  Smiting  the  scope  ot  specific  architectures 

-  planning  aid  managing  transition  bom  one  architecture  to  another 
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Ths  architecture  process  needs  to  be  made  explicit: 


S  Man thy 

-  Buskm$  modth  M  am  pr*tc*t9d  on  mrcM$ctor$ 

■  tcofBffMC  tofou  that  dhva  aechitoctufat  $  section 

-  tKftncfcw  *vaiib«y  tfrt  flta*  arcMtecfurt 

•  Uanaga 

*  mMM  mhliGliVMfiifi  itf)  ttpldf  rajoumj 
“  pahodc  nh/Mun  muniinl  nviiM 

■  iMUWi  Cfl^tMMonpfw  toMWflfoMiKfeiii 

•  LMm 

■  wfun  cU  atchhactuma  bacotna  aubopthnal 

•  business  modaiM  naad  rtMntinp 

-  *tian  an&tactunJ  cr*aria  naad  k*  ba  changed 
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CARDS  Aichttactur*  Workshop 

Profiting  from  Architectures 


•  Establish  form*/  architecture  assessment  wtthin  your  organization 
e  Avoid  proprietary  architecture*  unless  you  control  them 

•  Encourage  adoption  of  favorable  architecture » through  aggressive 
perception  management 

-  facts  on  potential  component  suppliers 

-  us*  neutral  thin)  parties  as  leverage 

-  useihamedia 

-  sea  your  management 

e  Provide  architecture  adoption  aan/ice*  to  your  customers 


l 


Do  nor  overcommit  to  an  architecture 

-  monitor  architecture-driving  conations 

-  reed  to  warning  signs  early 
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ARCHITECTURAL 

DEVELOPMENTS 

ARMY 

COMMAND  AND  CONTROL  SYSTEM 
COMMON  SOFTWARE  PROGRAM 


STANLEY  H.  LEVINE 
DEPUTY  PROJECT  MANAGER 
COMMON  HARDWARE  SOFTWARE 
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CASS  CODE  SIZE  ESTIMATES 


CSCI 

LINES  OF  CODE 
(X  1000) 

SYSTEM  SERVICES 

15 

SOLDIER-MACHINE  INTERFACE 

12 

SYSTEM  MANAGER 

8 

DATA  MANAGER 

10 

MESSAGE  HANDLER 

16 

COMMUNICATIONS 

27 

TOTAL 

88 

CASS  ARCHITECTURE  WORKING  GROUP 
(ARCHWG) 


PURPOSE:  TO  DEFINE  CASS  ARCHITECTURE  AND  THE  SOFTWARE 
BACKPLANE  REQUIREMENTS 


ACTIVITIES 

■  DEFINE  TOP-LEVEL  CASS  ARCHITECTURE  FUNCTIONS 

•  PREPARE  SOFTWARE  REQUIREMENTS  SPEC  AND  ADA 
SPECIFICATIONS  FOf?  THE  ITC 

•  DETERMINE  CASS  STANDARDS  AND  METRICS,  DEFINE  ADA 
BINDINGS,  SELECT  COMMON  APPLICATIONS 


CHAIR:  BRUCE  GRAY,  CSE 
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Near  Term  Architecture  Definition 
Methodology* 


TRww 


CDT 


Objective  Architecture  Definition 
Methodology 


CDT 


Comparison  of  Near  Term  Arch  with 
Objective  Arch 
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CDT 


Product  Availability  Issues 


TRliw 


•  Issue:  MCS  and  AFATDS  products  appear  to  be  the  best  match 
for  CASS  requirements  but  they  will  not  be  available  when  needed 
to  complete  product  evaluations  within  schedule 

•  Resolution: 

-  Meet  with  MCS  retarding  Loral  CSCIs  and  AFATDS  to 
develop  workarounds  (e.g^  Beta  Release,  draft 
documentation,  etc)  for  as  many  objects  as  possible 

-  Identity  alternate  products  for  near  term  and  develop  plans 
for  upgrading  CASS  when  AFATDS  and  MCS  products 
become  available 
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CDT  Activities 
and  Status 


TRww 
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CASS  Interim  Architecture 


maw 
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CASS  Objective  Architecture 


CDT 

lemma  Learned 

7S9ww 

Software  Reuse 

ffllv 

•  Recognise  Schedule  Risk  in  Your  Planning  Whan  Using  QFE 
Product* 

•  Rigorous  Product  Evaluations  Essential 

-  Eliminate  Immature  Products 

-  Reduce  Integration  Risk 

-  Ensure  Kay  Evaluation  Criteria  Hat  (Requirements, 
Architecture,  Rausa) 

•  8LOC  or  Numbers  of  Objects  Ars  Not  Accurate  Measures  of  tha 
Porting  and  Development  Effort  Associated  With  a  Release 

-  04l.lt  may  requite  IsaaoMott  to  port  a  large  product  from 
one  version  of  X-artndoeiWMOnF  to  another  Mian  to  port  a 
anal  product  from  tha  ICC  to  tha  ALSY8  compiler 

-  Some  Objects  Ar*  Vary  Large,  Soma  Are  Small,  and  Soma 
Hay  Be  Mostly  COTS 

•  The  Extant  and  Quality  of  tha  Documentation  of  Product*  to  be 
Ported  Has  a  Significant  Impact  on  tha  Cost  of  Each  Release 

•  Responsiveness  of  Product  Developers  to  COT  Technical 
Questions  end  Extent  Product  Developed  With  Naming 
Conventions  and  Coding  Standards  Affects  COT  Productivity 


CDT 

Lessons  Learned 

Software  Reuse  (continued) 

fflVV 

tasgndcn  and  Tart  10% 


The  extent  and  quality  of  the  documentation  of  products  to  be 
ported  has  a  significant  impact  on  the  cost  of  each  release 
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Lessons  Learned 
COTS  Interface 


— • 

mnr 


•  CASS  Developed  SWIntertece  Preferable  to  COTS  8/W 
Intertoce 

■  Preduct  Independence 
-PortebUty 

•  CASS  Developed  C0T8  8/W  Merfeee  Prevkfee  BFAe  a  S/W 
Leyer  Buffer  worn  COTS  Product  Chengee 
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FINAL  APPROACH  ORIGINAL  APPROACH 


CASS  REQUIREMENTS  DRIVEN  MCS  DESIGN  DRIVEN 

EMMDOED  EXCESS  MCS  FUNCnOtiAUTT,  LIMITED  NMMfMAJMN  njBUMUTY  AND  KWOWHAMCt  Of  CASS 

ATCCS  MESSAGE  PROCESSING  MCS  MESSAGE  PROCESSING 

tumm  pfMccsaawovnwBffWNosoFHaMaaNatJusTUMnF 

OBJECT  ORIENTED  FUNCTION  DECOMPOSITION 

utt  omcwTr  m  ew  MMrTBt«NOE  i  TMiafnaN  10  ema  mb  chanom 

EXPLOIT  MULTIPLE  SOURCES  RELY  ON  SINGLE  SOURCE 

MnmvTiD  MK.  MOW  ucar  TO  OET  aotic  or  THE  aonwMK 

ATCCS  PRODUCT  MANAGEMENT  BFA  PRODUCT  MANAGEMENT 

mmromt  CAK-MoewNMNCtFiiOMANOOM.nl 

CASS  AS  A  TOOLKIT  CASS  AS  A  SINGLE  ENTITY 

WNm  CAMASAKTOAOeJtCTSTMATCANUMEOMOeWtOBraY 

ACCESS  DISTRIBUTED  PROCESSES  PROCESSES  IN  A  COMPUTER 

•UPMKTS  mOCOMSnSTMM<TCDACMMSMUUIWOMSTATIOM,MAIMnTOUWm 


mWCNlM 
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CASS  INTER-SOFTWARE  COMMUNICATIONS  (ISC) 
REQUIREMENTS  DOCUMENT 

THE  ISC  REQUIREMENTS  DOCUMENT  ESTABLISHES  A  DISTRIBUTED 
PROCESSING  PARADIGM  AND  ARCHITECTURE  FOR  CASS 

THE  CASS  ISC  IS  ACCESSED  BY  MULTIPLE  ADA  PROGRAMS 
(Potentially  on  Multiple  Processor*)  VIA  ABSTRACT 
INTERFACES  DEFINED  FOR: 

•  A  LOWER-LEVEL  DIRECT  TRANSPORT  INTERFACE  (BCS) 

•  AN  UPPER-LEVEL  RPC  INTERFACE  (Distributed  Services) 

DEFINED  BY  THE  CASS  ARCHITECTURE  WORKING  GROUP  IN  1989/ 
1990 

INCLUDES  ADA  PACKAGE  SPECS  THAT  DEFINE  THE  BCS.  BASEO  ON 
THE  AFATDS  DESIGN 


REFERENCED  AND  BASELINED  BY  THE  CASS  SSS  IN  JUNE  1991 

UPCOMING  REVISION  PLANNED  TO  AMENO  ADA  SPECS  WITH  NEW 
AFATDS  BCS  DESIGN 
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Lesson  1 


Technically  acceptable  aolutions  were 
found  for  every  technical  issue. 


Corollary:  No  solutions  were  found  for 
technical  problems  that  became  political 
issues. 


■atm 
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Lesson  2 


Support  from  the  highest  management  levels 
makes  a  significant  difference  In  the 
Initiation  of  a  reuse-oriented  approach. 

Corollary  1 :  Even  small  amounts  of  financial 
and  programmatic  assistance  will  change  the 
attitude  of  the  participants  trying  to  deal  with 
the  implementation  problems. 

Corollary  2:  Without  the  unified  support  at 
the  top,  die  individual  projects  pursue  their 
own  best  interest 


TrHQM>. 


Lesson  3 


Put  the  very  best  people  that  can  be  made 
available  on  the  Job  of  requirements  definition 
and  architecture  description. 

The  two  most  Important  characteristics  tor 
these  people  are  technical  competence  and  the 
ability  to  work  as  members  of  a  team. 


TECHNICAL  ISSUES 


1 .  Focus  on  the  technical  issues  instead  of  the 
programmatic  and  budgetary  issues 

2.  Work  by  consensus 

3.  Develop  die  requirements  documents  from 
scratch  in  working  groups  with  technical 
representatives  of  all  major  users  (developers) 
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ACCS  COMMON  SOFTWARE  PROGRAM 

LESSONS  LEARNED 


Day  to  day  management  must  bs  driven  by  an  Independent  PM  with 
significant  customer  PM  involvement. 

Common  Software  must  have  a  separate  budget  line  not  subject  to 
customer  PM  budget  cuts  snd  user  priorities. 

The  PEO  must  control  and  expedite  top  level  requirements  management 
with  full  customer  PM  involvement 

Each  PM’s  program  must  be  tied  to  the  common  effort  both  In  the 
approval  and  the  budget  cycles. 

Use  of  common  products  snd  producing  common  products  must  be 
added  to  a  system's  formal  requirements  and  to  a  PM's  formal  mission. 

Do  not  use  the  common  modules  on  a  specific  program’s  products 
without  first  evaluating  the  robustness  snd  reusability  of  the  program, 
architecture,  and  design.  . 


STRUCTURAL  MODELS  IN  PROPOSALS 


FREDERICK  J.  SWARTZ 
WRIGHT  PATTERSON  AFB  OH 
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The  Training  System  Program  Office  is  a  wing-level 
organization  singularly  responsible  for  the  planning, 
contracting,  designing,  testing,  and  delivery  of 
sophisticated,  multi-million  dollar  training  aircraft  and 
aircrew/maintenance  training  devices  and  systems  to 
USAF  frontline  troops.  Products  enable  USAF  aircrews 
and  maintainers  to  train  like  they  fight 
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OUTLINE 


History  of  Structural  Models 
Overview  of  Structural  Models 
Use  of  Structural  Models  in  RFPs 
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Structural  Modeling 


•  A  Structural  Model  provides  a  high  level 
design 

-  structure:  classes  of  containers  for  functionality 

-  coordination:  captures  coordination  model  which 
specifies  communications,  synchronization  and  time 
management 

•  Ability  of  the  architecture  to  leverage 
development  through  structure 

•  Reusable  software  architecture  -  a  high  level 
embodiment  of  design  decisions 
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STRUCTURAL  MODELING 


Structural  Modeling  Addresses 

•  Development  Cost 

-  simplifies  and  standardizes  design 

-  provides  ability  to  make  decisions  early  In  process 

-  minimizes  assumptions  built  Into  designs 

-  promotes  reusability  (architecture,  design, 
implementations) 

•  Integration 

-  clear  picture  of  how  system  Is  constituted 

-  early  Integration  harness  provides  complete  model  of 
system 

-  allows  substitution  of  real  parts  for  models  In  incremental 
fashion 

-  reduced  integration  time,  fewer  surprises 


Structural  Modeling  Addresses 

•  Maintenance  Cost 

-  ‘robust’  under  modification 

-  mot*  sasfly  understood  by  maintainors 

-  predictability  In  coat  and  performance 

-  wad  defined  expectations  of  structure,  composition,  and 
coordination 

•  Aircraft  Currency 

-  close  mapping  to  aircraft  design 

-  wail  defined  interfaces  to  avionics  components 

-  tolerance  for  data  voids 
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STRUCTURAL  MODELS  IN 
PROPOSALS 


•  instructions  to  Offerer  (ITO) 

•  Describe  the  structural  Model(s) 

•  Demonstrate  modei(s)  is  complete 

-  Describe  how  modei(s)  will  be  applied 

•  Statement-of-Work  (SOW) 

-  Use  object  oriented  methods 

-  Ada  structural  modeling 

-  SSR  -  architectural  guidelines 

•  PDR  ~  Incremental 

•  CDR  -  Incremental 


431 


STRUCTURAL  MODELS  IN 
PROPOSALS 

•  System  Requirements  Documents 

•  Modularity 

•  Maintainability 
-  P3I 
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STRUCTURAL  MODELS  IN 
PROPOSALS 


•  What  else 

•  New  reviews 

*  Pre  SRR  -  Architecture  Guidelines  & 

SDP 

*  Pre  PDR  -  Structure  Model  Review  I 

*  Pre  CDR  -  Structure  Model  Review  il 

•  Guidebook 

•  SEI  produced 

-  Part  of  bidder  library 

•White  Paper  on  Structural  Modeling 
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STRUCTURAL  MODELS  IN 
PROPOSALS 
SUMMARY 


•  Structural  model  is  still  maturing 

•  Based  on  Object  Oriented  methodology 

•  Very  little  specifics  In  ITO,  SOW,  and  SRD 

•  Evaluating  approach  based  on: 

-  Risk 

-  Performance 

-  IIKIes 

•  Guidebook  will  give  the  basics 
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Central  Archive  for  Reusable 
Defense  Software 
(CARDS) 

Software  Architecture  Workshop 

16  November  1993 


Architecture  Forum  Workshop  - 17  November 

Purpose: 

•  Explore  the  current  practice  of  software  architectures  and  software  re¬ 
use  on  actual  projects 

•  Explore  current  research  into  architecture  as  a  means  of  implementing 
reuse 

Overview: 

•  Morning: 

-  Short  presentations  by  practitioners  and  researchers  on  their  current 
work  with  architectures 

•  Afternoon: 

-  Working  session  to  identify  common  problems  in  reuse 
implementation  and  develop  a  common  approach  to  solutions 
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Workshop  Schedule  17  November 

8:00  AM  Transitioning  from  research  to  practice  •  T.  Saunders,  Mitre 

8:30  AM  Architecture  as  the  framework  for  realizing  the  benefits  of  reuse 

-  W.Tracz,  IBM 

8:45  AM  Abstraction  and  layering  within  software  architectures 

-  M.  Gerhard,  ESL 

9:00  AM  Overview  of  DiSA  Software  Reuse  Domain  Analysis 

-  D.  Gary,  DISA 

9:15  AM  Software  Architecture,  Reuse,  and  Maintenance 
•  Jim  Baldo,  Unisys 

9:30  AM  Break 

9:45  AM  The  Object-Connection-Update  Architecture 

-Charles  Plinta,  ACCEL 
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Workshop  Schedule  17 November-  Continued 

10:00  AM  PRISM  software  architecture  •  P.  Valdez,  ESC/ENS 

10:15  AM  NSA  Unified  INFOSEC  Architecture  (UIA)  -  B.  Koehler,  DIRNSA 

10:30  AM  9LV  Mk3  shipboard  C2  architecture  -  U.  Olsson,  CelsiusTech 
Systems 

10:45  AM  Architectures  and  the  real  world,  based  on  the  Army  C2 
common  software  program  experience  -  S.  Levine,  Army 

11:00  AM  Break 

1 1 :15  AM  Architectures  in  the  CIS  field  •  applying  Christopher  Alexander’s 
work  -  J.  Bonine,  Design  Metrics  Technology 

11:30  AM  OO-based  architecture  use  at  NUWC  -  S.  Roodbeen,  NUWC 

11:45  AM  Capturing  domain  knowledge  at  NTF  -  T.  Gill,  NFT/ENS 


Workshop  Schedule  17 November-  Continued 

12:00  PM  STARS  demo  project  architecture  -  G.  Wickman,  CECOM 

12:15  PM  The  STARS  Air  Force  Demo  Project  *  K.  Spicer,  SWSC/SMX 

12:30  PM  Lunch  •  4th  Floor  Antechamber 

1:30  PM  Working  Groups 

4:30  PM  Working  Group  Report 

5:00  PM  Wrap-up 


Proposed  Working  Groups  and  Topics  - 17  November 


WQ 1 :  Evaluation  and  Measurement  of  Architectures 

-  procurement  mu—:  how  on  many  propoesd  architectures  bo  evaluated? 

-  design  Issues:  what  are  the  "architecture-lever  quantise  which  can  and  should  be 
measured? 

WQ  2:  Software  Architecture  Technologies 

-  what  are  the  current  and  emerging  technologies  tor  software  architecture? 

•  where  Is  tha  “low  hanging  fruir  (La.,  easily  attained  but  usaful  technology)? 

WQ  3:  Software  Architecture  and  Reuse 

-  what  does  It  mean  for  an  architecture  to  be  “reusable?" 

•  what  Is  needed  for  product-line  archltecturte  to  sustain  a  commercial  component 
provider  Industry? 

WQ  4:  Software  Architecture  and  Standards 

•  what  la  the  relationship  between  architecture  and  open  systems? 

-  what  are  areas  of  architecture  standardisation,  e-g.,  "bunding  codes?" 

WQ  8:  Software  Architecture  and  Strategic  (Product-Une)  Planning 

•  where  In  the  DoD  should  architectures  be  specified?  maintained?  implemented?  What 
are  the  prowcona  of  various  approaches? 

•  how  can  DoD  architectures,  If  specified,  be  used  prescriptlveiy  In  procuring  systems 


iber  17,  1993 
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ATHW  Canyny 
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Software  Architecture  Workshop 
for  the  CARDS  Community 

November  17, 1993 


J.  Chris  Commons  and  Msric  Gerhardt 
ESL,  Inc. 

485  Java  Drivs 

Sunnyvale,  CA  84088-3510 

(408)738-2888  • 


chris_eommonsOsmtp.esl.com  i 
gerhardtOaJpo4eLcmu.edu 
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What  Is  Architecture? 


•  Architectures  are  3  things 

-  Framework 

-  Behavior 

-  The  basis  for  extension  and  customization 

•  A  consequence  of  a  well  defined  framework  is 
predictable  behavior 


E8L 
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Domain  Specific  Software 
Architectures  (DSSA) 


•  Deals  with  sets  of  related  problems 

•  Does  not  mean  equivalent  final  solutions 

-  The  tame  architectural  framework 

-  Different  piece  parts  that  fit  into  the  framework  for 
different  problems 

-  Different  customize tions  on  top  of  the  architecture 

•  The  architecture  is  a  subset  of  what’s  shipped 
as  a  problem  solution 

-  Customized  to  solve  a  problem 


ESL 
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Current  vs.  Desired  Reuse 
Approaches 


•  C  ent  reuse  approaches  just  look  at  pieces 

-  te  structure  and  mindset  of  component 
respositories  is  that  all  components  are  combinable 

•  An  approach  is  needed  that  considers 
collection  of  pieces 

-  An  “architecture  oriented”  mindset 

-  Emphasize  the  cooperation  and  coordination  of 
pieces 

-  Understanding  the  consequences  of  using  groups 
of  pieces 

»  Behavior 

»  Resources  considerations 

»  Pathological  combinations 
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an  “architecture  oriented”  approach. 
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Lessons  Learned 


•  Interaction  side  effects  often  occur  when 
architectural  components  are  arbitrarily 
combined 

-  A  “failure"  of  our  abstraction  technology 

-  Information  about  low  level  resources  that  will  be 
committed  in  the  course  of  providing  a  service  is 
not  conveyed 

-  We  do  not  have  a  good  mechanism  to  encapsulate 
side  effects  or  behavior  effects  of  black  box 
components 
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Reuse:  Components  vs. 
Frameworks 


•  Reuse  is  not  just  components,  repositories, 
browsers 

•  Reuse  is  really  about: 

-  Generalization 

-  Layering 

-  Connectivity 

-  Non-point  solutions 

-  Collective  Behavior 

•  We  need  to  deal  with: 

-  Generality  and  its  cost 

-  Modularity  and  its  cost 

-  Shifting  complexity,  layering  (abstraction),  and 
generalization  from  architecture  byproducts  to  first 
class  concerns 

V _ a _ J 
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Architectures  and  Domains 
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DSSA  Development  -2 


•  Tradeoff  between  extensible  framework  or 
parametrized  problem-based  architecture 

-  Framework  example  -  spreadsheet 

-  parametrized  problem-based  example  •  UadnTax 

-  but  MaelnTax  is  constructed  via  an  Interaction  rule 
base  on  top  of  a  spreadsheet  anginal 


ESL 

A  TRW  Company 


DSSA  Development  -3 


•  SO:  MOST  important  -  DSSAs  result  from 
recursive  generation  of  successively  more 
abstract  composite  objects 

-  easily  repeatable  perceived  behavior 

-  easily  varying  access  to  internal  sublayers 


This  is  a  OSSA 


and  the  whole  pyramid  is  also  a  DSSA  f 


Overall  Concept 


*  Domain  Engineering  is  Ihe  systematic 
identification  of  commonalities  among  a  group  of 
related  software  systems 

•  Domain  Engineering  is  composed  of  three  major 
parts: 

-  Domain  Analysis 

-  Domain  Design 

-  Domain  Implementation 


Domain  Engineering  — 
The  Products...  Domain  Model 


•  Object  Oriented  Domain  Model 

•  Identifies  Common  Software  Objects  And 
Requirements  For  A  Family  Of  Systems 


XteJmmi  Diswin  Itelm 

Products  of  Domain  Design 


>  Domain  Specific  Software  Architecture  (DSSA) 

A  specification  for  assemblage  of  software  components  that  is: 

•  Specialized  for  a  particular  class  of  tasks  (domain), 

•  Generalized  for  effective  we  across  that  domain, 

•  Composed  in  a  standardized  structure  (topology), 

•  Effective  for  building  successful  applications. 

•  Minimally  provides  a  framework  for  specifying  the  major 
components  and  the  interfaces  that  satisfy  the  requirements,  iomtai 


•  Graphical  Diagram' 

•  Class/Object  Design  Specifications 


>  Domain  Design  Classification  Terms 


High-Level  DSSA  Diagram 


RETAIL  SUPPLY 


t  " 


Class/Object  Design 
Specification  -  Template  (corn) 


Connection:  ^ 

Instance:  achuslodjtct  name  with 
anUmtlity* 

Menace:  a^mjaar  ait*  tuoctmtd 


External  Interfaces:  <#ci.am»n 

«imMiarSar> 

*  Slate  Space:  ummuMc  m  diagramhmatrix> 
Attributes: 

Description:  <ki» 

Source(«):  <tta> 

♦  Traceability  la  Domain  Modd: 


Adaptation:  <tat> 

Traceability: 

*  Dowa  to  Detailed  Desica/Code: 

intonation  nmu  fc.f  Package 
gpcciflcatianti> 

*  Up  to  Domain  Modd): 

ipntotmjpactobjtttg, 

i  tdMlMU>  > 

V  »•)«  V 


Operations: 

Description:  <inn 
Soureets):  <t«o> 

*  Traceability  la  Deauia  Modd: 


<frvtnm»_4altnj 

Poetroadkioal: 

tfropmnjiaitnJ 


Rationale:  cm 
Tradeoff:  «ar> 


The  Laws  Nature,  the  Lost  Wisdom  of  the  ancients, 
and  the 

Common  Sense  of  Planning: 

Software  Architecture,  Reuse,  and  Maintenance 


Jamtt  Baldo  Jr. 

17  November  1993 

CARDS  ArckiUctun  Seminar 

haUofjetanremajenauuxom 


•  Early  1990's  data  indicates  that  corporate  expenditure*  for  software  is 
around  $100  blllion/yr. 

•  Approximately  $70  billion/yr  is  allocated  to  maintenance. 

•  If  maintenance  costs  increase  at  10%/yr  (at  the  same  rate  as  the  size  of 
system  growth),  then  over  a  ten  year  period  over  $1  trillion  will  be  spent 
on  maintenance. 

•  The  value  of  legacy  system  software  is  in  the  trillions  of  dollars  and  is 
usually  not  economically  feasible  to  replace. 

•  The  docamentatlon  of  legacy  system  software  in  some  cases  does  not 
exist,  not  adequate,  or  not  current. 


D.V. 


,  ACM  SIpA  Scftm  bfiKm,  town.  Wl  It,  No.  4.  Ocl  1993,  n-  *»■ -  *5. 


Architecture 


Fatal  Architectures 


Architecture 

Software  Architecture  Definition 
Software  Architectures  Context 
Software  Architectures  Benefits 
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User  Hostile  Architectures 


Reuse 


Development  of  reusable  assets  from  scratch  requires  a  huge  initial 
investment  of  human  capital,  real  capital,  and  time  that  gives  reuse  a 
long  lead  time  before  it  stars  to  pap  off  in  a  significant  way. 

A  promising  potential  cost  effective  approach  is  by  extracting  and  re* 
engineering  them  from  existing  software  systems. 


Premise: 

•  A  large  amount  of  knowledge  and  expertise  of  the  companies  that 
developed  and/or  use  a  software  system  can  be  retrieved  from  the 
same  system  in  different  forms  such  as  requirements  or  design 
documents,  code,  test  cases,  user  manuals,  maintenance  Journal. 

•  The  use  of  an  existing  software  system  to  extract  reusable  assets 
allows  part  of  this  knowledge  and  expertise  to  be  salvaged  in  order  to 
reapply  it  in  the  maintenance  of  the  original  system  or  in  the 
development  of  other  similar  systems. 


Some  Maintenance  Predictions 


•  Client-server  paradigm  to  grow  to  dominate  the  way  organizations 
(tructurc  their  computer  configuration*,  both  in  term*  of  hardware  and 
software.  The  additional  demands  on  application  and  system  software, 
data  communications,  database^  files,  and  transaction  Integrity  (to  note 
a  few  factors),  will  make  software  maintenance  more  difficult  in  a  client- 
sewr  environment 

•  Multiprocessing  in  several  forms  wfll  become  common,  and  expectation 
consistent  with  the  dient-erver  one.  This  adds  to  software 

an  additional  dimension  (multiprocessing)  to  be  understood  and 
maintained.  As  hardware  and  operating  systems  offer  ever  more 
multiprocessing  capability,  personnel  doing  software  maintenance  will 
increasingly  have  to  work  with  it 

* . t  '*•  ■■  ■  - -  -  •  i  -■  m  i n  iin 

t— spiei-et 


V,—!  ■  . . . . .  . .  Unisys— x 
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Workshop  Questions 


•  Can  software  architectures,  software  reuse,  and  software 
maintenance,  be  defined  and  governed  by  a  set  of  rules  to  effectively 
develop  and  evolve  software  systems? 

•  It  bas  been  estimated  that  “legacy  software”  is  in  the  order  of  trillions 
of  dollars.  The  maintenance  of  these  systems  consumes  a  large 
amount  of  the  software  budget,  approximately  70%.  Can  software 
architecture  and  software  reuse  be  used  to  address  these  issues? 


Unisys-^ 

naps  awe 
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Solution 


Architectures  supporting  Software  Maintenance 


the  OCU  Architectural  Model? 


and  Templates -Completed  Forms  and  Templates  -  Incomplete 


"Ftrm$  mmd 


What  is  the  OCU  Architectural  Model? 


through  •  tlngto  loftwara  omci 


ptual  Architecture 


Interface  Development 


CebiusTech 
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Gdteborg 

(4) 

SF300 

(7*64.3) 

I S/86 
(4) 

Rauma 

(4) 

ANZAC 

(10) 

Gotland 

(341) 

StriC 


The  Projects 

Displacement  (t)  Length  (m)  Armament 

380  57  Guns 

SSM 
ASW 

300  54  Gun 

{♦rote 
weapons) 

2700  112  Gun 


200  48  Gun 

SSM 

3225  118  Gun 

SAM 

1250  52  Torpedo 


Multi-site  national 
Air  Defence  System 
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The  Background 


Strategy 

•  Structure  for  reuse 

•  Use  recognized  standards  (open  systems) 

•  Emphasis  on  applications 

•  Produce  family  of  components 

•  integrate  components  into  a  system 


Classical  Multi-Project  Development 


time 


SIS 


Creating  a  Set  of  Components 


Customer  system  2 


Customer 
system  4 


time 
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Document  Model 
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The  situation  1993 

•  Several  systems  operational  with 
several  customers 

•  Highly  successful  firing  tests 

•  =2  MDSI  operational 

•  Stable  architecture 

•  High  quality  in  the  delivered 
software 

•  Demonstrated  portability 
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Software  Architectures 

Steve  Roodbeen 
Naval  Undersea  Warfare  Center 
Division  Newport,  Rl 
17  November  1993 


NUWC  Division  Newport 


Architecture 


The  Science,  Art,  Or  Profession  Of  Designing 
And  Constructing  Buildings,  Bridges,  Etc. 

The  Design  And  Integration  Of  Components  Of 
A  Computer  Or  Computer  System. 
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Software  Architecture 


•  The  Science,  Art,  Or  Profession  Of  Designing 
And  Constructing  Software,  Software  Systems, 
Etc. 

•  The  Design  And  Integration  Of  Software 
Components  In  A  Computer  Or  Computer 
System. 
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NUWC  Division  Ncv.poM 


Current  Emphasis 

•  Analysis,  Acquisition,  And  Integration  Of  Several 
Heterogeneous  Support  Software  Tools. 

•  All  Support  Software  Tools  Accessible  Through  A  Central 
interface. 

•  All  Software  System  Information  Accessftle  Through  A 
Central  Interface. 

•  List  Of  Tools  Includes:  CARDS  RLF,  SEE-Ada,  Rational 
Rose,  AOs  MAT,  and  Otyectmsker. 
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Current  Goal 


•  Analyze  Legacy  Software  Systems  And  Extract 
Design  Information. 


NUWC  Division  Newport 


Design  Capture 


•  Analysis  And  Extraction  Of  Design  Information  From 
Legacy  Software. 


An  Object-Based  View  Of  Functionally 
Designed  Code 


NUV7C  Division  Newport 


Architecture  Representation 

•  Primary  Representation  Vehicle  CARDS  RLF 

•  RLF  Selected  Due  To  Its  Robustness  (s-g..  Its  Ability  To 
Provide  Access  To  A  Variety  Of  Information). 

•  All  Other  Representation  Tools  Can  Be  Launched  From  The 
RLF.  Basically,  RLF  Provides  An  Open  Interface  To  Other 
Tools 


r.'UWC  Dam  .ion  Noivport 


Lessons  Learned 

•  Developer's  Reluctant  To  Provide  Design 
Information 

•  Design  Information  May  No  Longer  Be  Available 

•  Information  That  Is  Available  Is  Incorrect  Or 
Obsolete 

•  It  Is  Difficult  To  Incorporate  The  New  Software 
Engineering  Paradigm  Into  The  Design  Process  (he., 
Now  Is  A  Tuff  Time  To  Change  The  Way  We  Do 
Business) 
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The  Ultimate  Goal 

•  Define  Process  Which  Will  Result  In  The 
Generation  Of  Reusable  Software  Systems/ 
Subsystems/Components 

•  Object  Oriented  Technology 

•  New  Tools  Emerging  To  Support  This  Approach 

•  Expand  Software  Architecture  To  Include 
Everything  Known  About  A  Given  System 
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TWO  KINDS  OF  DOMAIN 


SYSTEMATIC  APPROACH  TO  IEW  REUSE 
(CONTD) 


S 


'  sonwAxciMaoaziMiDaKroKA're  • 


ODM  DOMAIN  ANALYSIS  REFERENCE  MODEL 

Reusable  Assets 

. _ i _ L _  _ 


Asset  Implementation 


|  Descriptive  Analysis 
[  Prescriptive  Analysis 


Asset  Implementation 
Planning 


Domain 

Stakeholder 

Input 


1  Exemplar  Workproduds 


Domain  , 
Architecture 


PRESCRIPTIVE  ANALYSIS 
SOLUTION  SPACE 


Implementation 


irmtu  vtNuatMMOMmATMN  muter 

domam  ncMBBUMo  •  me  noBucr4M  AmOAca 


AirForce/STARS 
Demonstration  Project 
Space  Command  &  Control 
Architectural  Infrastructure  (SCAI) 


Capt  Kelly  L.  Spicer,  USAF 

Lead,  Domain  Engineering  St  Reuae  Working  Group 

17  November  1993 

Space  and  Warning  Sysemi  Center 

Air  Forex  Space  Command 

SW SC/S  MX,  Slop  2320, 130  W.  Paine  St 
Peteraon  AFB,  Co,  80914-2320 

(719)554-6675 

kspicet@xpacecotn.af.mil 
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TARGET:  REFINE  LAYERS  TO  SCAI 
ARCHITECTURE 


MISSIOI 
I  LAYER 


COl 
>  layer. 


Awfcniw 

Ui»  , 


698  "i*~- 

©SERVER 

... 


LAYER 

OUCQ 


UNAS 


luk. 


a*.  c(?tihw  nmmerm 

POStX  Qttf  Trifcwli 


VTAJUf/AJI  VOICE  PEMIMST*  AT!  ON  PROJECT 
DOMAIN  ENGINEERING  -  SWSC  PRODUCT4JNE  APPROACH 


REFINE  LAYERS  TO  SCAI 
ARCHITECTURE 


•  Abstract  Display-User  Interaction  Classes  Into  Mission  Objects/ 
Classes 

•  Define  Standard  Structure  For  Mission  Objects 

•  Continue  to  Refine  Layering  Scheme: 

•  ‘Standardize  Layer  Interfaces  (e.g.  Common  Layer) 

•  ‘Define  Standardized  Interface  to  RICC  Tools 

•  Define  Consistent  Display  Interface  Paradigms 

•  Extend  Scope  of  00  Analysis  to  Other  Missions  Besides  Space 

•  Extend  RICC  “Layer"  To  Include  Additional  Tools 


jfefM«WW?*ca/»MaCAkDS.*CMM4(K 


_ wwnr  mmmamuTiuw  muter 

•OMAmnaranm'MaciMowMjraAfiwuai 

Building  die  Product-Line  Organization 
[Functional  Organization  Mimics  Architecture  Layering] 


s 

[Mission  Experts] 

common  Services 

(Dm*  Bmc,  Di^Uyi,  Menage  WMetion] 

[Software  Engineers! 

»L  R1CC  Experts  J _ P 

1 

■ 

i 

^^Implementation/Architecturc 

i _ i 

- - T3T- 

- 
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APPLICATION 

BASED 

SYSTEM 


SYSTEM  EXAMPLE: 

A(R  COMMAND  CENTER 
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application 

BASED 

SYSTEM 


s 


CONCEPT: 

.  EA(«  SYSTEM  ELEMENT  BBELFCOWnureD.PROVBWG  ALL  HAAOWARE 
AMD  SOFTWARE  NECESSARY  TO  ESCUTE  FTS  TASK 

.  EACH  SYSTEM  EUEIKMT  CAN  OPERATE  M  A  STAND-ALONE  MODEM  THE 
EVENT  COHMUMCATKM  OVER  C*l  NETWORK  IS  NOT  POSSSLE 

.  BASER  TO  DEVELOP  AND  UAM1AM  THAN  CONVENTIONAL  SYSTEMS 

.  PHOVBES  A  8BVLE  SOLUTION  TO  SECURITY  PROBLEMS  UNTIL  MORE 
ROBUST  PRODUCTS  ARE  DEVELOPED 

.  SUPPORTS  1HARSK1  OF  COMPUTE  RESOURCES  TO  ALLOW  PARALLEL  AND 

OSTRISUTED  PROCESSMQ  BMPLOYMO  OTHERWISE  UNDERUSED 
COMPUTE  RESOURCES 


APPLICATION 

BASED 

SYSTEM 


APPROACH  DESCRIPTION: 
ITERATIVE  PROCESS 


•  BEMOFY  TASKS  AND  WORKFLOW  USING  THE  ABC  METHOD 

•  BENTFY  SECURITY  REQUIREMENTS  FOR  EACH  TASK 
.  DENTFY  DATA  RECHMREMENTS  FOR  EACH  TASK 

•  ANALYZE  DATA  AND  CONTROL  INTERFACES  BETWEEN  TASKS 


APPROACH  DESCRIPTION: 


•  DECOMPOSE  SYSTEM  SnOFUNCTMMALTASK  GROUPS  BASED 
UPON  ANALYSIS  PERFORMED  MRS  PREVIOUS  STEPS. THESE 
TASKS  GROUPS  SHOULD  BE  ORGAMZBI  SUCH  THAT 
COMMUMGATION  BETWEEN  THEM  HAVRE  ACCOMPLISHED  GY 
MMPtE  MESSAGES.  THB  RESULTS  M  A  SYSTEM  SEGMENT 

Sfi CORCATXMFOR  EACH  TASK  GNOUP 

•  OEFNE  DATA  BASE  STRUCTURES  REQURED  FOR  EACH  TASK 
GROUR  DATABASES  COMMON  AMONG  TASK  GAOUP8  SHOULD 
SHARE  THE  SAME  SSORMKnQH  CONTENTS  ORDER  TO  SUPPORT 
RELOCATION  OF  APPLICATION  CODE.  TIGS  RESULTS  IN  A  DATABASE 
OBCmmON  DOCUMENT 

.  OERNE  MESSAGES  USED  TO  COMMSCKTE  BETWEEN  TASK 
GROUPS.' THIS  RESULTS  M  AN  M7ERKICEOE8K2N  DOCUMENT 

•  ITERATE  OVER  THE  ABOVE  STEPS  UKTS.  A  SUITABLE  ARCHriECTURE 
ISACHEVEO 


V 


CLASSICAL  DEVELOPER-WRITTEN  DATABASE 
APPLICATION  PROGRAM  INTERFACE  (API) 


APPLICATION 

uaeo 

SYSTEM 


CONCLUSION: 

THE  APPLICATION  BASED  SYSTEM  ARCHITECTURE  PROYBES  A 

USTNOOOLOOV  FOR  ADDRESSMQ  AND  80LYMQ  MANY  OF  THE 
ISSUES  FAONG  SWEDEN  FOR  DCVELOPMQ  A  COMPLEX  C*l 
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Mr.  J.  Chris  Commons . ESL,  Inc. 

Mr.  Dick  Crops . Unisys 

Mr.  Paul  Dumanoie . DOD/Army  STRICOM 

Mr.  Jim  Estep . Unisys/CARDS 

Mr.  Jeff  Facemire . Azimuth/CARDS 

Dr.  Peter  Feiler . Software  Engineering  Institute/CMU 

Ms.  Karen  Fleming  ...Strictly  Business  Computer  Systems/CARDS 

Ms.  Deborah  Gary . DISA/CSRO 

Mr.  Mark  Gerhardt . ESL,  Inc. 

Mr.  Mark  Gerken . AFTT/ENG 

Mr.  Terry  Gill . National  Test  Facility 

Dr.  Robert  Gillespie . WVT 

Mr.  Chandra  Gollypudy . CERC 

Mr.  Nicholay  Gradetsky . CERC 

Mr.  Paul  Gregory . Unisys/CARDS 

Ms.  Kerri  Haines . Unisys/CARDS 

Ms.  Kammi  Hefner . Electronic  Warfare  Associates 

Mr.  Scott  Hissam . Unisys/CARDS 

Mr.  John  James . Intermetrics 

Mr.  Dan  Juttlestadt . NUWC 

Mr.  Erik  Karikoski . Unisys  Sweden 

Mr.  Stellan  Kamebro . Syst.  Tech. 

Mr.  Perry  Koger . Electronic  Warfare  Associates/CARDS 

Mr.  Paul  Kogut . Unisys/CARDS 

Mr.  Jim  Law . D.N.  American/CARDS 

Mr.  Roy  Lawson . CERC 

Mr.  Bob  Lencewicz . ESD/ENS 

Mr.  Stanley  Levine . CECOM 

Mr.  Ed  Liebhardt  II . MountainNet 


A-l 


STARS- VC-B008/D01/D0 


29  January  1994 


Mr.  Quiang  Lin . Galaxy  Global  Coiporation/CARDS 

Mr.  Bill  Loftus . . . WPL  Labs,  Inc. 

Mr.  Pete  Maravelias . USAF 

Ms.  Lorraine  Martin . Unisys/CARDS 

Mr.  Dan  McCaugheity . Intermetrics 

Mr.  Steven  Merritt . DIS  A 

Mr.  Mike  Nichol . ASC/EN(CR) 

Mr.  Dan  Nichols . Electronic  Warfare  Associates/CARDS 

Mr.  Ulf  Olsson . CelsiusTech 

Mr.  A.  Spencer  Peterson . SE1/CMU 

Ms.  Aleisa  Petracca . Azimuth/CARDS 

Mr.  Jim  Petro . ...Electronic  Warfare  Associates/CARDS 

Mr.  Charles  Plinta . Accel 

Mr.  Hans  Polzer . Unisys 

Mr.  Jay  Reddy . Strictly  Business  Computer  Systems/CARDS 

Mr.  Stephen  Riesbeck . :. . Azimuth/CARDS 

Mr.  Steve  Roodbeen . NUWC 

Mr.  Robert  Rutherford . SofTech,  Inc. 

Mr.  Skip  Saunders . Mitre  Corp. 

Mr.  Evan  Schmidt . .  Electronic  Warfare  Associates 

Mr.  Bill  Schwartz . DoD 


Ms.  Jennie  Shipe . SofTech,  Inc. 

Mr.  Mark  Simos . Organon  Motives 

Dr.  Thomas  J.  Smith . Mitre  Coip. 

Ms.  Catherine  Smotherman . Unisys 

Mr.  Charlie  Snyder . Unisys/CARDS 

Mr.  Michael  Sobolewski . CERC 

Dr.  Nancy  Solderitsch . Unisys/CARDS 

Capt  Kelly  Spicer . SWSC/SMX 

Major  Frederick  Swartz . ASC/YTEC 

Mr.  Robert  Terry . MountainNet 

Mr.  Will  Tracz . IBMFSC 


Capt  Paul  Valdez . 

Mr.  Kurt  Wallnau . 

Mr.  Mike  Webb . 

Mr.  Bob  Webster . 

Mr.  Roger  Whitehead- 
Major  Grant  Wickman 


. ESC/ENS 

. Unisys/CARDS 

. SEI 

. ESC/ENS 

DSD  Laboratories/CARDS 
. CECOM 


STARS-VC-BOOMJOlflO 


29  January  1994 


Mr.  Dennis  Ahem 
Westinghouse  Electric 
P.O.  Box  746,  MS  432 
Baltimore,  MD  21203-0746 

Mr.  Robert  Allen 
CMU 

Science  Hall  8214 
Pittsburgh,  PA  15217-3890 

Capt  Emily  Andrew 
National  Test  Facility 
730  Irwin  Ave. 

Falcon  AFB,  CO  80912-7300 

Ms.  Rose  Arms'trong 
DSD 

1401  Country  Club  Rd. 
Fairmont,  WV  26554 

Ms.  Pam  Aiya 
General  Research 
1900  Gallows  Road 
Vienna,  VA  22182 

Mr.  Ali  Babadi 
CERC 

P.O.  Box  6506 
Morgantown,  WV  26506 

Major  Paul  Bailor 
AFIT/ENG 
2950  P  Street 

Wright-Patterson  AFB,  OH  45433-6583 

Mr.  James  Baldo 
CARDS 

2010  Sunrise  Valley  Drive 
Reston,  VA  22091 

Mr.  Christopher  Bengtsson 
C3I 

S-115  88  Stockholm 
Sweden 


STARS-VC-B008AX31/00 


Mr.  Eric  Beser 
12344  Greenspring  Ave. 
Owings  Mills,  MD  21117 

Mr.  Vincent  Bia 
NTF 

730  Irwin  Ave.,  MS  N9000 
Falcon  AFB,  CO  80909 

Mr.  James  Bonine 
Design  Metrics 
2  Cedar  Tree  Lane 
Stamford,  CT  062903 

Mr.  Wayne  Brandt 
CERC  * 

P.O.  Box  6506 
Morgantown,  WV  26506 

Ms.  Linda  Brown 
OASD 

1225  Jefferson  Davis  Highway 
Arlington  VA  22202 

Mr.  J.  Chris  Commons 
ESL,  Inc. 

495  Java  Drive 
Sunnyvale,  CA  94088-3510 

Mr.  Dick  Creps 
Unisys 

12010  Sunrise  Valley  Drive 
Reston,  VA  22091 

Mr.  Paul  Dumanoie 
DoD/Army  STRICOM 
12350  Research  Parkway 
Orlando,  FL  32826-3276 

Mr.  Jim  Estep 
Unisys 

1401  Country  Club  Rd.,  Suite  102 
Fairmont,  WV  26554 


29  January  1994 


I 


A-4 


STARS-VOBOOS/OOIAX) 


29  Jammy  1994 


Mr.  Jeff  Facemire 
Azimuth 

1401  Country  Qub  Rd.,  Suite  204 
Fairmont,  WV  26554 

Dr.  Peter  Feiler 
SEVCMU 

Carnegie  Mellon  Univ. 
Pittsburgh,  PA  15213-3890 

Ms.  Karen  Fleming 
SBI 

12  Moran  Circle 
Fairmont,  WV  26554 

Ms.  Deborah  Gary 
CSRO 

500  N.  Washington  St,  Suite  200 
Falls  Church,  VA  22046 

Mr.  Mark  Gerhardt 
ESL,  Inc. 

495  Java  Drive 
Sunnyvale,  CA  94088-3510 

Mr.  Mark  Gerken 
AFIT/ENG 
2950  P.  Street 

Wright-Patterson  AFB,  OH  45433-7765 

Mr.  Terry  Gill 
National  Test  Facility 
730  Irwin  Avenue 
Falcon  AFB,  CO  80912-7300 

Dr.  Robert  Gillespie 
WVT 

West  Virginia  Tech 
Montgomery,  WV  25136 

Mr.  Chandra  Gollypudy 
CERC 

P.O.  Box  6506 
Morgantown,  WV  26506 


STARS-VC-BOO800 1  AX) 


Mr.  Nicholay  Gradetsky 
CERC 

P.O.  Box  6506 
Morgantown,  WV  26506 

Mr.  Paul  Gregory 
Unisys 

1401  Country  Club  Rd.,  Suite  102 
Fairmont,  WV  26554 

Ms.  Kerri  Haines 
Unisys 

1401  Country  Club  Rd.,  Suite  102 
Fairmont,  WV  26554 

Ms.  Kammi  Hgfner 
EWA 

1401  Country  Qub  Rd. 
Fairmont,  WV  26554 

Mr.  Scott  Hissam 
Unisys 

1401  Country  Club  Rd.,  Suite  102 
Fairmont,  WV  26554 

Mr.  John  James 
Intermetrics 

Mr.  Dan  Juttlestadt 
NUWC 

Building  1171, 3rd  Floor 
Newport,  RI 02841-4612 

Mr.  Erik  Karikoski 
Unisys  Sweden 

Mr.  Stellan  Kamebro 
Syst.  Tech 
S-115  88  Stockholm 
Sweden 

Mr.  Perry  Koger 
EWA 

1401  Country  Club  Rd. 
Fairmont,  WV  26554 


29  January  1994 


A-6 


Mr.  Paul  Kogut 
Unisys 

1401  Country  Club  Rd.,  Suite  102 
Fairmont,  WV  26554 

Mr.  Jim  Law 
DNA 

1401  Country  dub  Rd. 
Fairmont,  WV  26554 

Mr.  Roy  Lawson 
CERC 

P.O.  Box  6506 
Morgantown,  WV  26506 

Mr.  Bob  Lencdwicz 
ESD/ENS 
Bldg.  1704 

Hanscom  AFB,  MA  01731-5000 

Mr.  Stanley  Levine 
CECOM 

7 10  Carol  Avenue 
Ocean,  NJ  077 12 

Mr.  Ed  Liebhardt  n 
MountainNet 
2705  Cranberry  Sq. 
Morgantown,  WV  26505-9286 

Mr.  Quiang  Lin 
Galaxy  Global 
1401  Country  Club  Rd. 
Fairmont,  WV  26554 

Mr.  Bill  Loftus 
WPL  Labs,  Inc. 

410  Lancaster  Ave.,  Suite  6 
Haverford,  PA  19041 

Mr.  Pete  Maravelias 
USAF 

ESD/AVS,  Bldg.  1704 
Hanscom  AFB,  MA  01731-5000 


STARS-VC-BOO&OOIAO 


Ms.  Lorraine  Martin 
CARDS 

4  Militia  Dr.,  Suite  11 
Lexington,  MA  02173 

Mr.  Dan  McCaugherty 
Intermetrics 

Mr.  Steven  Merritt 
DISA 

500  N.  Washington  St 
Falls  Church,  VA  22046 

Mr.  Mike  Nichol 
ASCTEN(CR) 

1865  4th  SL,  Suite  11 
Wright  Patterson  AFB,  Ohio  45433-7126 

Mr.  Dan  Nichols 
EWA 

1401  Country  Club  Rd. 
Fairmont,  WV  26554 

Mr.  Ulf  Olsson 
CelsiusTech 
S-175  88  Jarfalla 
Sweden 

Mr.  A.  Spencer  Peterson 
SEI/CMU 

Carnegie  Mellon  Univ. 
Pittsburgh,  PA  15213-3890 

Ms.  Aleisa  Petracca 
Azimuth 

1401  Country  Club  Rd.,  Suite  204 
Fairmont,  WV  26554 

Mr.  Jim  Petro 
EWA 

1401  Country  Club  Rd. 

Fairmont,  WV  26554 


29  January  1994 


A -8 


STARS-VC-B0Q8/001J0O 


29  January  1994 


Mr.  Charles  Plinta 
Accel 

449  Maple  Avenue 
Pittsburgh,  PA  15218 

Mr.  Hans  Polzer 
Unisys 

12010  Sunrise  Valley  Dr. 
Reston,  VA  22091 


Mr.  Jay  Reddy 
SBI 

12  Moran  Circle 
Fairmont,  WV  26554 

Mr.  Stephen  Riesbeck 
Azimuth 

1401  Country  Club  Rd. 
Fairmont,  WV  26554 

Mr.  Steve  Rood  been 
NUWC 

Bldg.  1171-3,  Code  2221 
Newport,  RI 002841-1708 

Mr.  Robert  Rutherford 
SofTech,  Inc. 

P.O.  Box  210386 
Montgomery,  AL  36121-0386 

Mr.  Skip  Saunders 
Mitre  Corp. 

202  Burlington  Rd. 
Bedford,  MA  01730 

Mr.  Evan  Schmidt 
CARDS 

1401  Country  Club  Rd.,  #201 
Fairmont,  WV  26554 

Ms.  Jennie  Shipe 
SofTech 
Alexandria,  VA 


STARS-VC-B0O8fl0iy00 


29  January  1994 


Mr.  Marie  Sim  os 
Organon  Motives 
36  Warwick  Road 
Watertown,  MA  02172 

Dr.  Thomas  J.  Smith 
Mitre  Coip. 

752 S  Colshire  Drive  MS:W197 
McLean,  VA  22102 

Ms.  Catherine  Smotherman 
Unisys 

1401  Country  Club  Rd.,  Suite  102 
Fairmont,  WV  26554 

Mr.  Charlie  Snyder 
Unisys 

1401  Country  Club  Rd.,  Suite  102 
Fairmont,  WV  26554 

Mr.  Michael  Sobolewski 
CERC 

P.O.  Box  6506 
Morgantown,  WV  26506 

Dr.  Nancy  Solderitsch 
Unisys 

1401  Country  Club  Rd.,  Suite  102 
Fairmont,  WV  26554 

Captain  Kelly  Spicer 
SWSC/SMX 
130  W.  Paine  St. 

Peterson  AFB,  CO  80914-2320 

Major  Frederick  Swartz 
ASC/YTEC 
2240  B  St.,  Suite  7 

Wright-Patterson  AFB,  OH  45433-7111 

Mr.  Robert  Terry 
MountainNet 
2705  Cranberry  Sq. 
Morgantown,  WV  26505 


A- 10 


STARS-VC-B008/D01AX) 


29  January  1994 


MtTOnitecz 
IBM,  FSCMD  0210 
1801  State  Route  17c 
Owego,  NY  13827-3994 

Capt  Paul  Valdez 
ESCVENS 

Bldg.  1704,  Rm  107 

Hanscom  AFB,  MA  01731-2116 

Mr.  KurtWallnau 
Unisys 

1401  Country  Club  Rd.,  Suite  102 
Fairmont,  WV  26554 

Mr.  Mike  Webb 
SEI 

Carnegie  Mellon  University 
Pittsburgh,  PA  15213-3890 

Mr.  Bob  Webster 
ESD/ENS,  Bldg.  1704 
Hanscom  AFB,  MA  01731-5000 

Mr.  Roger  Whitehead 
CARDS 

75  Union  Avenue 
Sudbury,  MA  01776 

Major  Grant  Wickman 
CECOM 

AMSEL-RD-SE-R-ESD-SPT 
Ft.  Monmouth,  NJ  07703 


STARS-VC-B008/D01/00 


29  January  1994 


APPENDIX  B  -  BIBILIOGRAPHY 

The  following  sources  were  used  for  the  development  of  Seminar  materials. 

Abowd,  et  aL,  “Structural  Modeling:  An  Application  Framework  and  Development  Process 
far  Flight  Simulators.”  Technical  Report  CMU/SEI-93-TR-14,  Software  Engineering 
Institute,  1993. 

Air  Force  Institute  of  Technology  and  the  Software  Engineering  Institute,  “Putting  the 
Engineering  in  Software  Engineering.”  Annotated  briefing,  Carnegie  Mellon  University. 

Alexander,  C.,  “Notes  on  the  Synthesis  of  Form.”  Harvard  University  Press,  ISBN  0-674- 
62750-4, 1964. 

Alexander,  G,  “The  Timeless  Way  of  Building.”  Oxford  University  Press,  ISBN  0-19- 
502402-8. 

Apple  Macintosh  “MacAPP  Developer’s  Kit  Documentation.” 

Arango,  G.,  Prieto-Diaz,  R.,  “Domain  Analysis  Concepts  and  Research  Directions.”  Domain 
Analysis  and  Systems  Modeling,  IEEE  Computer  Society  Press,  ISBN  0-8186-8996-X,  1991. 

Arango,  G.,  Schoen,  E.,  Pettengill,  R.,  “A  Process  for  Consolidating  and  Reusing  Design 
Knowledge.”  Proceedings  of  The  15th  International  Conference  on  Software  Engineering, 
May  17-21, 1993. 

Arango,  G.,  Schoen,  E.,  Pettengill,  R.,  “Design  as  Evolution  and  Reuse.”  Proceedings  of  the 
Second  International  Workshop  on  Software  Reusability,  March  24-26, 1993. 

Arango,  G.,  Schoen,  E.,  Pettengill,  R.,  Hoskins,  J.,  “The  Graft-Host  Method  for  Design 
Change.”  Proceedings  of  The  15th  International  Conference  on  Software  Engineering,  May 
17-21, 1993. 

Balzer,  R.,  “Model  Management  Examples.”  Proceedings  of  DSS  A  VII  Workshop. 

Balzer,  R.,  “Design  Refinement  in  DSSAs.”  Proceedings  of  the  JSGCC  Software  Initiative 
Strategy  Workshop,  December  1992. 

Barr,  Feigenbaum,  Cohen,  “The  Handbook  of  Artificial  Intelligence.”  Vols.  I-TV,  1981-89. 

Batory,  D.,  O’Malley,  S.,  “The  Design  and  Implementation  of  Hierarchical  Software  Systems 
with  Reusable  Components.”  Technical  Report  TR-91-22,  University  of  Texas  at  Austin, 
Texas,  January  1992. 

Booch,  G.,“Software  Components  with  Ada.”  1987. 


B-l 


STARS-VG-B008/30 1/DO 


29  January  1994 


Booch,  G.,  “Object-Oriented  Design  with  Applications.”  1991. 

Booch,  G.,  “Next  Generation  Methods  -  Bringing  Order  Out  of  the  Chaos.”  Journal  of  Object 
Oriented  Programming,  Supplement  on  00  Analysis  and  Design,  July/August  1993. 

Braun,  “DSSAs:  Approaches  to  Specifying  and  Using  Architectures.”  STARS  92,  December 
1992. 

Bryan,  D.,  Rapide-0.2  Language  and  Tool-Set  Overview.  February  1992. 

Buschmann,  “Rational  Architectures  For  Object-Oriented  Software  Systems.*’  Journal  of 
Object-Oriented  Programming,  September  1993. 

Callahan,  J.,  Purtillo,  J.,  “A  Packaging  System  for  Heterogeneous  Execution  Environments.” 
IEEE  Transactions  on  Software  Engineering,  Vol.  17,  No.  6,  June  1991. 

Coad,  P.,  “Object-Oriented  Patterns.”  Communications  of  the  ACM,  Vol.  35,  No.  9, 
September  1992. 

Commons,  J.C.,  Gerhardt,  M„  “A  Model  for  Analyzing  Megaprogramming,  Reuse,  and 
Domain  Specific  Software  Architectures.”  TRI-Ada,  September  1993. 

Cox,  “Planning  the  Software  Industrial  Revolution.”  IEEE  Software,  November  1990. 

Datapro  “Reports  on...”,  updated  periodically. 

Devanbu,  P.,  Brachman,  R.J.,  Selfridge,  P.G.,  Ballard,  B.W.,  “LaSSIE:  A  Knowledge-Based 
Software  Information  System."  Communications  of  the  ACM,  May  1991. 

Dumas,  “Designing  User  Interfaces  for  Software.”  1988. 

Estrin,  G.,  Fenchel,  R.,  Razouk,  R.,  Vemon,  M.,  “SARA  (System  ARchitects  Apprentice): 
Modeling,  Analysis,  and  Simulation  Support  for  Design  of  Concurrent  Systems.”  EEEE 
Transactions  on  Software  Engineering,  Vol.  SE-12,  No.  2,  February  1986. 

Feiler,  P.,  “Configuration  Management  Models  in  Commercial  Environments.”  Technical 
Report  CMU/SEI-91-TR-7,  Software  Engineering  Institute,  1991. 

Fischer  G.,  “Human  Computer  Interaction  Software:  Lessons  Learned,  Challenges  Ahead.” 
IEEE  Software,  January  1989. 

Freeman,  P.,  “A  Conceptual  Analysis  of  the  Draco  Approach  to  Constructing  Software 
Systems.”  IEEE  Transactions  on  Software  Engineering,  SE-13,  July  1987. 


B-2 


STARS-VC-B008/D01/30 


29  January  1994 


Gamma,  E.,  Helm,  R„  Johnson,  R.,  Vlissides,  R.,  “Design  Patterns:  Abstraction  and  Reuse  of 
Object  Oriented  Design.”  Unpublished  paper.  Contact  Erich  Gamma  at  Thligent,  Inc.,  10725 
N.  De  Anza  Blvd.,  Cupertino,  CA  95014-2000. 

Garlan,  D.,  Shaw,  M.,  “An  Introduction  to  Software  Architecture.”  To  appear  in  Advances  in 
Software  Engineering  and  Knowledge  Engineering,  Volume  I,  World  Scientific  Publishing 
Company,  1993. 

Garlan,  D.,  Scott,  C.,  “Adding  Implicit  Invocation  to  Traditional  Programming  Languages.” 
Proceedings  of  The  15th  International  Conference  on  Software  Engineering.  May  17-21 
1993. 

Garlan,  D.,  Kaiser,  G.E.,  Notion,  D.,  “Using  Tool  Abstraction  to  Compose  Systems.”  IEEE 
Computer,  June  1992. 

Gelerator,  D.,  Carriero,  N.,  “Coordination  Languages  and  Their  Significance.” 
Communications  of  the  ACM,  Vol.  35,  No.  2, 1992. 

Goguen,  “Reusing  and  Interconnecting  Software  Components.” 

Griss,  M„  Informal  Presentation  Charts.  WISR6,  November  3-5, 1993. 

Harel,  D.,  eLal.,  “STATEMATE:  A  Working  Environment  for  the  Development  of  Complex, 
Reactive  Systems.”  Technical  Report,  10th  ICSE,  1988. 

IEEE  Std  610.12  -  IEEE  Standard  Glossary  of  Software  Engineering  Terminology.  December 
1990. 

Journal  of  Object-Oriented  Programming,  September  1993. 

Kazman,  R.,  Bass,  L.,  Abowd,  G.,  Webb,  M.,  “Analyzing  Properties  of  User  Interface 
Software.”  To  be  released  as  a  Technical  Report,  Software  Engineering  Institute,  Carnegie 
Mellon  University. 

Knuth,  “The  Art  of  Computer  Programming.”  Vols.  I-HI,  1973. 

Krueger,  C.  W.,  “Software  Reuse.”  ACM  Computing  Surveys,  Volume  24,  Number  2,  June 
1992. 

Lakoff,  G.,  “Women,  Fire  and  Dangerous  Things:  What  Categories  Reveal  About  The  Mind.” 
University  of  Chicago  Press,  ISBN  0-226-46803-8, 1991. 

Lane,  T.  G.,  “Studying  Software  Architectures  Through  Design  Spaces  and  Rules.”  Technical 
Report  CMU/SEI-90-TR-18,  Software  Engineering  Institute,  1990. 


B-3 


STARS-VC-BOO&OOIAX) 


29  January  1994 


Lee,  Rissman,  D’lppolito,  Plinta,  Van  Scoy,  “An  OOD  Paradigm  far  Flight  Simulators.” 
Technical  Report  CMU/SEI-88-TR-30,  Software  Engineering  Institute,  1988. 

Lowry,  “Software  Engineering  in  the  Twenty-First  Century."  AI  Magazine,  Fall  1992. 

Lowry,  M.  R.,  McCartney,  R.  D.,  “Automating  Software  Design.”  AAAI  Press,  1991. 

Lubars,  M.D.,  “A  General  Design  Representation.”  Technical  Report  STP-066-89,  MCC 
Corp.,  Austin,  Texas,  1989. 

Lubars,  M.  D.,  “Representing  Design  Dependencies  in  an  Issue-Based  Style.”  IEEE  Software, 
My  1991. 

Luckham,  D.C.,  von  Henke,  “An  Overview  of  Anna:  a  Specification  Language  for  Ada.“ 
IEEE  Software,  March  1985. 

Luckham,  D.C.,  Vera,  J.,  “jARapide:  An  Executable  Architecture  Definition  Language.”  April 
1993. 

Luckham,  D.C.,  Vera,  J.,  “Event-Based  Concepts  and  Language  for  System  Architecture.” 
March  1993. 

Metalla,  E.,“Domain-Specific  Software  Architectures.”  STARS  92  Annotated  Briefing,  1992. 

Mettala,  E.,  “The  Domain  Specific  Software  Architecture  Program.”  DARPA  Software  Tech¬ 
nology  Conference,  April  1992. 

Meyer,  B.,  “Object-Oriented  Software  Construction.”  Prentice-Hall,  1988. 

Neighbors,  J.M.,  “The  Draco  Approach  to  Constructing  Software  from  Reusable 
Components.”  IEEE  Transaction  on  Software  Engineering,  SE-10,  September  1984. 

Neighbors,  J.M.,  “Draco:  A  Method  for  Engineering  Reusable  Software  Systems.”  Frontier 
Series:  Software  Reusability:  Volume  I  -  Concepts  and  Models,  ACM  Press,  1989. 

Neighbors,  J.M.,  “Draco:  The  Evolution  From  Software  Components  to  Domain  Analysis.” 
International  Journal  of  Software  Engineering  and  Knowledge  Engineering.  Vol.  2,  No.  3, 
September  1992. 

Nierstrasz,  O.,  Gibbs,  Tsichritzis,  “Component  Oriented  Software  Development.” 
Communications  of  the  ACM,  Vol.  35,  No.  9,  September  1992. 

OMG,  “The  Common  Object  Request  Broker:  Architecture  and  Specification.”  1992. 

OMG,  “Object  Management  Architecture  Guide.”  September  1992. 


B-4 


STARS-VC-B008/D0 1/DO 


29  January  1994 


Patel-Schncider,  PFL,  Brachman,  RJ.,  Levesque.,  HJ„  “Argon:  Knowledge  Representation 
Meets  Information  Retrieval.”  Proceedings  of  fee  First  Conference  on  Artificial  Intelligence 
Applications,  1984. 

Payton,  T.,  “Domain-Specific  Reuse.”  STARS  92  Annotated  Briefing,  1992. 

Peny,  Chilton,  “Chemical  Engineers’  Handbook.”  5th  ed.,  1973. 

Perry,  D.E.,  Wolf,  A.,  “Foundations  for  the  Study  of  Software  Architecture.”  ACM  SIGSOFT 
Software  Engineering  Notes,  VoL  17,  No.  4,  October  1992. 

Peterson,  S.,  “Mapping  a  Domain  Model  and  Architecture  to  a  Generic  Design.”  CMU/S El- 
Technical  Report,  draft 

Peterson,  S.,  “Coming  to  Terms  with  Software  Reuse  Terminology:  A  Model-Based 
Approach.”  ACM  SIGSOFT  Software  Engineering  Notes,  April  1991. 

Purtilo,  J.,  “Software  Bus  Organization:  Reference  Model  and  Comparison  of  Two  Existing 
Systems.”  ARPA  Module  Interconnection  Formalism  Working  Group  Technical  Note  Series, 
TN  No.  8,  November  1991. 

Royce,  W.,  Brown,  D.,  “Architecting  Distributed  Realtime  Ada  Applications:  The  Software 
Architect’s  Lifecycle  Environment.”  Ada  DC,  1991. 

Salasin,  J„  Waugh,  D.,  “An  Approach  to  Analyzing  Non-Functional  Aspects  During  System 
Definition.”  Draft  Technical  Paper,  Proceedings  of  the  ARPA/DSSA  VII  Workshop. 

Saunders,  Horowitz,  Mleziva,  “A  New  Process  for  Acquiring  Software  Architecture.”  MITRE 
Corporation,  1993. 

Sedgewick,  “Algorithms  in  C.”  1990. 

Sedgewick,  “Algorithms  in  C++.”  1992. 

Selfridge,  P.G.,  “Knowledge  Representation  Support  for  a  Software  Information  System." 
Proceedings  of  the  7th  Conference  on  Artificial  Intelligence  Applications,  February  24-28, 
1991. 

Selfhdge,  P.G.,  Terveen,  L.G.,  Long,  M.D.,  “Managing  Design  Knowledge  to  Provide 
Assistance  to  Large-Scale  Software  Development."  Proceedings  of  the  7th  Knowledge-Based 
Software  Engineering  Conference,  September  1992. 

Shaw,  M.  “Prospects  for  an  Engineenng  Discipline  of  Software.”  IEEE  Software,  November 
1990. 


B-5 


STARS-VOB008j001A» 


29  January  1994 


Shaw,  M.,  “Larger  Scale  Systems  Require  Higher  Level  Abstractions.**  5th  International 
Workshop  on  Software  Specification  and  Design,  May  1989. 

Simos,  M.,  “Organizational  Domain  Modeling.**  STARS  Technical  Report,  Unisys 
Corporation. 

Singhal,  V.,  Batory,  D.,  “P++:  A  Language  for  Software  System  Generators.’*  Technical 
Report  TR-93-16,  Department  of  Computer  Science,  University  of  Texas  at  Austin,  1993. 

Taft,  “Ada  9X:  A  Technical  Summary.*’  Communications  of  the  ACM,  November  1992. 

Tracz,  W.,  “LELEANNA;  A  Parameterized  Programming  Language.’’  Proceedings  of  the 
Second  International  Workshop  on  Software  Reusability,  March  24-26, 1993. 

Tracz,  W.,  “A  Conceptual  Model  for  Megaprogramming.**  ACM  SIGSOFT  Software 
Engineering  Notes,  July  1991. 

UNAS  Training  Class,  TRW  Systems  Engineering  &  Development  Division,  DH2/1271, 
Carson,  CA,  July  7-9, 1993. 

Zachman,  J.,  “A  Framework  for  Information  Systems  Architecture.”  IBM  Systems  Journal, 
Vol  26,  No.  3, 1987. 


The  following  sources  are  recommended  for  those  interested  in  additional  information. 

Agrawala,  Jackson,  Vestal,  “Domain-Specific  Software  Architectures  for  Intelligent 
Guidance,  Navigation  and  Control.”  DARPA  Software  Technology  Conference,  April  1992. 

Bailin,  S.,  “KAPTUR:  Knowledge  Acquisition  for  Preservation  of  Tradeoffs  and  Underlying 
Rationales.”  Unpublished,  1993. 

Belz,  Luckham,  Purtilo,  “Application  of  ProtoTech  Technology  to  the  DSSA  Program.” 
DARPA  Software  Technology  Conference,  April  1992. 

Bhansali,  Nii,  “Software  Design  by  Reusing  Architectures.”  Proceedings  of  the  7th 
Knowledge-Based  Software  Engineering  Conference,  September  1992. 

Braun,  Hatch,  Ruegsegger,  Balzer,  Feather,  Goldman,  Wile,  “Domain  Specific  Software 
Architectures  -  Command  and  Control.”  DARPA  Software  Technology  Conference,  April 
1992. 

Coglianese,  Goodwin,  Smith,  Tracz,  Batory,  Bellman,  Gries,  McAllester,  Selby,  Taylor,  “An 
Avionics  Domain-Specific  Software  Architecture.”  DARPA  Software  Technology 
Conference,  April  1992. 


B-6 


STARS- VOBOOSflOlJOO 


29  January  1994 


Coglianesc,  TYacz,  Newton,  McAllester,  Goguen,  Taylor,  Selby,  Batary,  “DSSA-ADAGE.” 
DSSA  VH  Briefing,  July  1993. 

Dasgupta,  S.,  “A  Hierarchical  Taxonomic  System  for  Computer  Architectures.”  IEEE 
Computer,  March  1990. 

Davis,  A.,  “A  Comparison  of  Techniques  for  the  Specification  of  External  System  Behavior.” 
CACM,  September  1988. 

Fichman,  Kemerer,  “Object-Oriented  and  Conventional  Analysis  and  Design  Methodologies: 
Comparison  and  Critique.”  IEEE  Computer,  October  1992. 

Fowler,  M.,  “OO  Methods:  A  Comparative  View.”  Journal  of  Object  Oriented  Programming, 
Supplement  on  OO  Analysis  and  Design,  July/August  1993. 

Graham,  L,  “Object-Oriented  Methods.”  Addison  WeSley,  1991. 

Gruber,  T.,  “Toward  principles  for  the  design  of  ontologies  used  far  knowledge  sharing.” 
Unpublished  report,  January  1993. 

Guindon,  R.,  “The  Knowledge  Exploited  by  Experts  During  Software  System  Design.”  MCC 
STP-032-90, 1990. 

Hayes-Roth,  F.,  Ennan,  Terry,  Hayes-Roth,  B.,  “DSSA:  Distributed  Intelligent  Control  and 
Management  Applications  and  Development  Support  Environment”  DARPA  Software 
Technology  Conference,  April  1992. 

Jullig,  R.,  “Applying  Formal  Software  Synthesis.”  IEEE  Software,  May  1993. 

Lalum,  C.,  “Analysis  of  DCDS  Data  Model.”  STARS  CDRL  3048R,  January  1991. 

Lee,  J.,  “The  1992  Workshop  on  Design  Rationale  Capture  and  Use.”  AI  Magazine,  Summer 
1993. 

Long,  Morris,  “An  Overview  of  PCTE:  A  Basis  for  a  Portable  Common  Tool  Environment.” 
CMU/SEI-TR-93- 1 , 1993. 

Lubars,  M„  “The  ROSE-2  Strategies  for  Supporting  High  Level  Software  Design  Reuse.” 
Automating  Software  Design,  1991. 

Lubars,  M.,  “Domain  Specific  Software  Architectures.”  MCC  STP-RU-043-91,  February 
1991. 

Meadow,  C.  L.,  Latour,  L.,  “Layered  Generic  Architectures:  A  Methodology  for  the 
Construction  of  Reusable  Software  Components.”  Prepared  for  the  US  Army  CECOM  Center 
for  Software  Engineering,  July  1991. 


B-7 


STARS  WC-BOOdOO  1/00 


29  January  1994 


Monarchi,  Puhr,  “A  Research  Typology  for  Object-Oriented  Analysis  and  Design.”  CACM, 
September  1992. 

Neches,  Fikes,  Finin,  Gruber,  Patil,  Senator,  Swartout,  “Enabling  Technology  for  Knowledge 
Sharing  ”  AI  Magazine,  Fall  1991. 

Platek,  R.,  “DSSA's  for  Hybrid  Control.”  DARPA  Software  Technology  Conference,  April 

1992. 

Schwanke,  Altucher,  Platoff,  “Discovering,  Visualizing,  and  Controlling  Software  Structure.” 
5th  International  Workshop  on  Software  Specification  and  Design,  May  1989. 

Software  Technology  Support  Center,  “Requirements  Analysis  and  Design  Tools  Report” 
April  1992. 

Tracz,  Coglianese,  Young,  “Domain-specific  SW  Architecture  Engineering.”  ACM  SIGSOFT 
Software  Engineering  Notes,  October  1992. 

Tracz,  W.,  “Megaprogramming  and  Domain  Engineering  Tutorial."  ICSE  15,  May  1993. 

Tracz,  Shafer,  Coglianese,  “DSSA-ADAGE  Design  Records.”  ADAGE-IBM-93-05,  July 

1993. 

Vestal,  S.,  “A  Cursory  Overview  and  Comparison  of  Four  Architectural  Description 
Languages.”  Informal  technical  report,  February  1993. 

Vestal,  S.,  “Host  Environment  Support  for  Architecture-Oriented  Toolsets.”  Informal 
technical  report,  March  1993. 

Webster,  D.,  “Mapping  the  Design  Information  Representation  Terrain.”  IEEE  Computer, 
December  1986. 

Wiederhold,  Wegner,  Ceri,  “Toward  Megaprogramming.”  CACM,  November  1992. 

Wood,  Pethia,  Gold,  Firth,  “A  Guide  to  the  Assessment  of  Software  Development  Methods  ” 
Technical  Report  CMU/SEI-88-TR-8, 1988. 


B-8 


